How to quickly verify and build your idea

Using the mom test and personal lessons

👋 Hey, it’s Orel here! Welcome to my weekly newsletter where I share my journey and lessons as an entrepreneur who quit his job to chase his dreams.

I am a software developer, and so far I have x3 failed projects, and x2 ongoing.

I am also publishing along with

Anton Zaides

tech book summaries weekly here

I have learned quite a lot since releasing PinkyPartner.

And not only from releasing it and getting feedback.

When you start publishing your products, your mind is more open to ideas to improve in the fields that will make your new product better.

So books like “The Mom Test”, about which I will elaborate more in a few seconds, was a fantastic read for me. It gave me a lot of insights into how I verify my ideas and why I did it all wrong.

So in today’s article I am going to share my framework for creating a new product. From verifying it to preparing everything before you start writing a line of code and tips for when you do start.

Key takeaways

1. Verify your ideas with the mom test (hint: don’t pitch).

2. create a plan with primary and nice-to-have tasks.

3. Have a strict deadline, make it short-term.

4. Pick the right tech stack for you.

5. Don’t sweat the small stuff.

Verify your idea

When I first had the idea of writing a product to help people build habits together, PinkyPartner, I thought it was just a great idea. I didn’t think I need to verify it.

Also I came up with a fantastic name and the .com url was free! (pinkypartner.com)

But still, my girlfriend pushed me to ask people and make sure it’s something people would use. So, I asked a friend and my sister. Here’s the gist of the conversations:

Me: “Hey, what do you think about X? I want to make an app that does that”
Sister/friend: “That sounds great! Fantastic idea, go for it.”

This is the worst mistake you can do when you want to verify your idea.
Not only that you didn’t get any valuable information, you got a compliment from people who are close to you. It’s usually a red flag.

Why? Because these people care about you. They will not tell you that it’s an awful idea and that you should drop it immediately.

The goal of verifying your idea

When you want to make sure that your product is good, you need to get as much unbiased information as you can. And the people you’ll asked are probably biased.

So, you need to ask the right questions and steer the conversation in your direction, while hiding the fact that you want to build something.

The easiest way to do it is to treat your “verifying questioning” as a regular coffee conversation.

Here’s a shortened example from the book of how NOT to do it.
The idea: digital cookbooks for the iPad.

Son: “Mom, mom, I have an idea for a business — can I run it by you?” I am about to expose my ego — please don’t hurt my feelings.
Mom: “Of course, dear.” You are my only son and I am ready to lie to protect you. The Son: “You like your iPad, right? You use it a lot?” Mom: “Yes.” You led me to this answer, so here you go
Son: “Okay, so would you ever buy an app which was like a cookbook for your iPad?” I am optimistically asking a hypothetical question and you know what I want you to say.
Mom: “Hmmm.” As if I need another cookbook at my age.
Son: “And it only costs $40 — that’s cheaper than those hardcovers on your shelf.” I’m going to skip that lukewarm signal and tell you more about my great idea.
Mom: “Well...” Aren’t apps supposed to cost a dollar?

…

Mom: “Oh, well yes honey, that sounds amazing. And you’re right, $40 is a good deal. Will it have pictures of the recipes?” I have rationalised the price outside of a real purchase decision, made a non-committal compliment, and offered a feature request to appear engaged.

Now you feel like your idea is a killer one and that you can go all in with it. This is the worst case.

It’s better to have not asked at all, because when you know you’re clueless, you tend to be careful.

Now let’s see a good example of verifying your idea:

Son: “Hey mom, how’s that new iPad treating you?”
Mom: “Oh - I love it! I use it every day.”
Son: “What do you usually do on it?” Whoops — we asked a generic question, so answer to this probably won’t be terribly valuable.
Mom: “Oh, you know. Read the news, play sudoku, catch up with my friends. The usual.”
Son: “What’s the last thing you did on it?” Get specific about examples in the past to get real, concrete data.
Mom: …
Son: “Did you use an app for that?” A slightly leading question, but sometimes we need to nudge to get to the topic we’re interested in.
Mom: “No, I just used Google. I didn’t know there was an app. What’s it called?” Younger folks use the App Store as a search engine, whereas your mom waits for a specific recommendation. If that’s true more broadly, finding a reliable marketing channel outside the App Store is going to be crucial.
Son: “Where did you find out about the other ones you use?” Dig into interesting and unexpected answers to understand the behaviours and motivations behind them.
Mom: “The Sunday paper has a section on the apps of the week.” You can’t remember the last time you cracked open a paper, but it sounds like traditional PR might be a viable option for reaching customers like your mom.
Son: “Makes sense. Hey, by the way, I saw a couple new cookbooks on the shelf — where did those come from?” Business ideas usually have several failure points. Here it’s both the medium of an iPad app and the content of a cookbook.
Mom: “They’re one of those things you just end up getting at Christmas. I think Marcy gave me that one. Haven’t even opened it. As if I need another lasagna recipe at my age!” Aha! This answer is gold dust for 3 reasons:
1. Old people don’t need another generic set of recipes.
2. The gift market may be strong.
3. Younger cooks may be a better customer segment since they don’t yet know the basics.
Son: “What’s the last cookbook you did buy for yourself ?” Attack generic answers like “I don’t buy cookbooks” by asking for specific examples.
Mom: “Now that you mention it, I bought a vegan cookbook about 3 months ago. Your father is trying to eat healthier and thought my veggies could benefit from a pinch more zazz.” More gold: experienced chefs may still buy specialised or niche cookbooks.

Now this conversation has generated tons of valuable information about way more than your product idea. From here, if you feel like mom could be a viable client, you can steer the conversation more towards your product, again without revealing it and that it’s yours, to get more specific answers.

Have a plan and a deadline

What I found out when I was writing Pinky Partner is that it felt 10x times harder without a solid plan of what I want to accomplish.

So I created a page in Notion and wrote:

Before release are things that are an absolute must.
Secondary are nice to haves.

Now, having “nice to haves” is meaning less without a deadline.

Think about it, if you have no time of when you finish writing, what difference does it make if you have primary goals and secondary goals? You’ll eventually get to both of them before the release, so you might as well just write a long to do list and get to work.

When you have a deadline, these things matter. And the shorter the deadline, the more thought you need to put on what goes into the Before release and what doesn’t.

Keep in mind that these can change as you code, because things you thought are simple might not be so (Like notifications for a PWA app, which took me over 1 week to accomplish), and vice versa.

Build it.

Now that you have verified your idea and you have a plan+deadline, it’s time to get to building!

The first step of building anything is having the right tools for the job. In our case, we need to choose a tech stack to work with.

Tech stack

You should choose your stack based on your previous experience and needs.

For example, if you want to build and ship as fast as possible and also have the option to deploy mobile apps, you’ll go with a framework you know very well that can be a PWA as well.

For me, the answer was React.

→ You can learn React Native at any time, which, for the most part, has the same syntax

→ You can deploy a web app as a mobile app, thanks to PWA technology progress.

Itzy Sabo

wrote about PWA in depth in his article

→ React is the most used front framework in 2023, according to statisa, by far. That means that there are plenty of resources in case I am stuck with something.

And here’s the rest of the stack:

AI:

Copilot and ChatGPT.

If there’s one thing that will completely transform the speed at which you write code, it’s Copilot. It writes 70% of my code.

Front:

1. React(TS), TailwindCSS
   To be honest, for the most part it doesn’t matter which framework you choose. Pick something that you’re comfortable with and code.

2. Next + Vercel
   Next handles a lot of headache and boilerplate code , which makes developing that much faster.
   Plus, you write both your front and your back ends in the same project and deploy them at the same time, which is awesome.
   And with Vercel, you deploy your website with a push of a commit :)

Backend:

1. Node (TS)
   Same as React. Pick what you like and go with it.

2. MongoDB
   Firestore doesn't work with Prisma and this was the first easy-to-use db I found that does.

3. Firebase, NextAuth
   For file storing and authentication.
   Hands down, NextAuth is the best and faster library to set up in order to authenticate a user and confirm authorization in the backend.’

Now that you have your tech stack ready, it’s time to build it!

Here are the top lessons I learned from writing PinkyPartner:

Tips for building faster and better

1. Build the your product with a mobile first approach
   ↳ Mobile app on desktop looks okay most of the times.
   Desktop app on a mobile device looks awful 99% of the times.
   ↳ Tailwind is built with a mobile-first approach, so that writing for mobile first and then adjusting for desktop is the native way.

2. Don’t sweat the small stuff
   Remember that your first and main goal is get people to use your product. Adding cool animations and beautiful buttons is worthless for people who don’t sign up. And the next point will clarify it further

3. Give value. As fast as possible
   90%+ of the people will not move beyond the landing page to sign up and use your product.
   Make sure you give them enough value and details about the product, as fast as possible, so that they want to sign up.

4. Have a short onboarding process
   If your product involves a task that is not very common, write a short and concise onboarding, preferably interactive, so that people don’t get lost and leave because they don’t know what to do.

5. Use common words
   The first mistake I did in PinkyPartner is using words that 99% of the people will not instinctively know what they are used for.

   I, for example, used the word Obligations instead of Promises, which is far more related to the website’s name and more relatable.

   

Final words

Eventually, this is my experience and my view of the world.

Some of you might find all or most of it useful, some might love only a thing or two.

The best way to learn is by doing yourself and sharing your progress and lessons.

So get to work, and let me know what you found useful in your process!

📣 What I enjoyed reading this week

John Rush #May20: SEO in 9 steps & 300k ARR by

John Rush

- A very interesting and in-depth article about how John takes care of his websites SEO.
*Saved for future use

Emotional signposting: Why you should tell people how to feel by

Wes Kao

- Wes shares practical tips on how to improve message delivery to avoid common misunderstandings by the receiving side.