Many makers say you should “sell it before you build it” or “build the community before the product”. For those who’ve been there, what actually worked for you - and what mistakes did you make along the way?
16 views
Replies
Best
Hey Doina,
I believe validating demand and deeply understanding customer needs before committing to extensive product development it's the priority.
I've been reading a lot of contents about Jobs to be Done in Product that helped a lot with this. JTBD provides a good framework for building smarter by focusing on demand first, like:
Understanding Customer Progress and Struggles: JTBD posits that customers "hire" products to make progress in their lives, not just to buy them. It flips the traditional product-centric view to ask: "What job is this customer trying to get done, and what progress are they hiring this product to help them make?". JTBD suggests starting product strategy with the "struggling moment" a customer faces, asking what was happening before they sought a solution. Your product backlog should be filled with user problems, not just feature ideas.
Shifting from Supply-Side to Demand-Side Thinking: Most product development is "supply-side," focusing on what features can be built next. JTBD shifts this to a "demand-side" approach, asking: "What job is the customer trying to get done? What’s their struggle? What are they trying to improve?". This means focusing on understanding the customer's desired outcomes rather than just shipping features.
Demand-Side Research: Instead of surface-level surveys, JTBD research goes deeper to understand what caused someone to start looking for a solution and what they were trying to solve. This involves interviewing people about their journey, reconstructing the timeline of their struggles, and understanding what made them commit to a solution.
Prototyping for Learning: JTBD suggests prototyping to test why a solution matters, not just if it works. The goal is to see if the prototype helps the customer achieve their desired progress and if they express genuine excitement or relief ("finally!") rather than just a casual "cool". Early tests should measure learning, uncovering demand, friction, and fit before committing to full development.
Prioritizing Based on Real Demand: JTBD provides tools and frameworks, like Tony Ulwick’s Outcome-Driven Innovation, to prioritize based on real demand rather than guesswork. This allows teams to simulate trade-offs and forecast what will matter before shipping. Prioritization can be based on criteria like "Job Severity x Frequency".
Building for Functional, Emotional & Social Progress: Customers hire products for emotional and social reasons, not just functional ones. For instance, an invoicing tool doesn't just send invoices; it helps someone feel confident about getting paid on time (emotional) and looking professional (social). Product design should support all three dimensions.
You should definitely check more contents about JTBD. It will help you avoid many mistakes by first understanding your customer needs, struggles, and desired progress before building a product.
This approach aims to provide "clarity about what job you really solve. Who struggles most. Why they switch. How they succeed," ultimately helping product teams to "build less, but better" and create products that customers truly depend on.
Replies
Hey Doina,
I believe validating demand and deeply understanding customer needs before committing to extensive product development it's the priority.
I've been reading a lot of contents about Jobs to be Done in Product that helped a lot with this. JTBD provides a good framework for building smarter by focusing on demand first, like:
Understanding Customer Progress and Struggles: JTBD posits that customers "hire" products to make progress in their lives, not just to buy them. It flips the traditional product-centric view to ask: "What job is this customer trying to get done, and what progress are they hiring this product to help them make?". JTBD suggests starting product strategy with the "struggling moment" a customer faces, asking what was happening before they sought a solution. Your product backlog should be filled with user problems, not just feature ideas.
Shifting from Supply-Side to Demand-Side Thinking: Most product development is "supply-side," focusing on what features can be built next. JTBD shifts this to a "demand-side" approach, asking: "What job is the customer trying to get done? What’s their struggle? What are they trying to improve?". This means focusing on understanding the customer's desired outcomes rather than just shipping features.
Demand-Side Research: Instead of surface-level surveys, JTBD research goes deeper to understand what caused someone to start looking for a solution and what they were trying to solve. This involves interviewing people about their journey, reconstructing the timeline of their struggles, and understanding what made them commit to a solution.
Prototyping for Learning: JTBD suggests prototyping to test why a solution matters, not just if it works. The goal is to see if the prototype helps the customer achieve their desired progress and if they express genuine excitement or relief ("finally!") rather than just a casual "cool". Early tests should measure learning, uncovering demand, friction, and fit before committing to full development.
Prioritizing Based on Real Demand: JTBD provides tools and frameworks, like Tony Ulwick’s Outcome-Driven Innovation, to prioritize based on real demand rather than guesswork. This allows teams to simulate trade-offs and forecast what will matter before shipping. Prioritization can be based on criteria like "Job Severity x Frequency".
Building for Functional, Emotional & Social Progress: Customers hire products for emotional and social reasons, not just functional ones. For instance, an invoicing tool doesn't just send invoices; it helps someone feel confident about getting paid on time (emotional) and looking professional (social). Product design should support all three dimensions.
You should definitely check more contents about JTBD. It will help you avoid many mistakes by first understanding your customer needs, struggles, and desired progress before building a product.
This approach aims to provide "clarity about what job you really solve. Who struggles most. Why they switch. How they succeed," ultimately helping product teams to "build less, but better" and create products that customers truly depend on.