I always start from the Jobs-to-be-done framework. I don’t think that great startup ideas pop out of nowhere- I think they are discovered by observing jobs that arise in the world.
By the way, that’s also how we decided to build avopos.
Great products (or services) succeed because they do the Job-to-be-done better than the alternatives
Recommended Pre-read: How to build great products
Here are some frameworks for discovering startup ideas using the Jobs-to-be-done (JTBD) framework:
(3) Lower Coordination Cost
(4) Luxury at scale
(5) Reduce Adoption Friction
(6) Low NPS incumbents
(7) Solving issues due to older solutions
(8) One improved…
When I picked up coding, technical software tasks immediately became less daunting. The unfortunate side-effect was that I started developing the unhealthy mentality that features were “cheaper” than they were in the past.
Features (even small ones) are not free.
Why is that?
We are incredibly biased towards short-term thinking. We get so caught up in the short-term pain that we lose sight of the long-term side effects.
When we contemplate new features, we tend to consider only the following costs:
(1) Time required to scope the feature
(2) Time required to design the feature
(3) Time required to develop the…
Product marketing is one of the many competencies required to bring a product to market.
Your job is to basically answer one question:
What does your product or service do?
The reason product marketing is difficult because you are trying to select the “goldilocks” level of abstraction for your product’s description.
Your answer might be too…
(a) Specific vs Broad
(c) Undifferentiated vs Confusing
(d) Too complex to understand vs Too simple to be valuable
(e) Functional vs Emotional
I have been guilty of this on numerous occasions. As interviewers, we want the ideas we are validating to work out.
We invested hours, maybe weeks, thinking about our ideas.
Because we are so invested, we fall victim to “happy-ears-syndrome”.
Happy Ears Syndrome: Hearing only what you want to hear
The more “scientific” term here: False Positive
Common symptoms of Happy Ears Syndrome include:
1. Imaginary customer pain
2. Abnormally optimistic founders
3. Terrible headaches (after product launches)
The output of user research shouldn’t just be the transcript of conversations.
I know that the research process is incredibly tiring but insight synthesis is a must.
The goal of this is to have enough clarity about your user’s job-to-be-done to produce a Netflix movie about it.
We want to build an app to help professionals expand their professional network.
Hypothesis: Professionals want to expand their social network but find it hard to do so because it is a huge time commitment.
If you feel bad after reading this, I have made every single mistake here.
At this point, I have probably sat through, watched, or conducted close to 100 hours of user interviews…
…and I still make 2 out of 10 of these mistakes from time to time.
There are only four things you really need to prepare for user interviews.
I’m not sure why, but…
…a common mistake is to be under-prepared with the interview parameters but over-prepared with questions
Think of a user’s life as a canvas filled with interesting topics:
The common mistake is drawing a large and vague box and stuff it with questions:
I grew up loving math. Math was easy.
You can always break down complex equations into simpler component parts.
Startups aren’t like math exams (Or are they?)
When you are first coming up with ideas and testing your initial hypothesis, it seems impossible to get everything right. There are too many moving parts.
You have to build a product that’s better than what's out there in the market and you have to find customers willing to purchase that product.
This sounds simple in theory but it is really really really hard to do. Why?
For the sake of this post…
I think we can classify product risk into two broad categories: Supply-side risk & Demand-side risk.
Supply-side risks describe risks that occur as you try to bring the product to market.
Demand-side risks describe risks that occur assuming the product can be brought to market.
Not all risks are created equal
The reason I’m writing this post:
Help founders and product managers think through different tests when validating concepts. When you build a validation framework or your MVP, you want to first decide which type of risk you are trying to tackle.
Validate your biggest risks first
These risks describe…
If you work in product, I guarantee you’ve heard this question before:
“How long will this feature take?”
Variants of this question include:
There are 3 variables for any developer to consider when providing a time estimate: Experience, Dependencies, and Degree of Complexity.
Have you done something similar in the past? Would it be a cut and paste feature that you’ve built before
Full-time PM. Part-time Indie Hacker. I write about my own SaaS journey + Product Management lessons for bootstrappers & early stage startups.