The majority of product founders and leaders build a product then go and find a customer for that product.
Their main concerns are:
Will I be able to get users to trial my product?
Will users get enough value out of my product to drive into the funnel beyond trial?
Will the primitive usability of my product prevent people converting?
What should I build next to move through alpha and beta (e.g. payments functionality; enhanced features)
How can I ensure I constantly and consistently deliver new functionality to users? Will I have the development resource to do this?
They have fallen into the start-up build trap. Focusing on outputs over outcomes and how features can be cranked out quickly to deliver value.
Many, including Melissa Perri, have written about ‘the build trap’ in the context of larger, established organisations but few about how the build trap effects start-ups.
I’ve built digital products and then tried to find my first customer and I’ve also found a paying customer and then built something for them.
It took weeks getting a customer to buy based on Photoshop mock-ups (a very large fleet company), before that I’d spent 10 years on and off building a product that no-one purchased. Build first, customer second is painful and risky. It wastes valuable time, money and passion!
Now I only follow the second approach: customer 1st, build 2nd. I will only build if I have a paying customer (ideally more) or at least a solid commitment to pay (even if that payment is deferred).
Lean software development, Lean start-up and Lean UX design thinking have taught use the benefits of:
- Learning and experimentation over selling
- Leaving build until the last responsible moment
- The importance of understanding and eliminating risk in product development (especially the value risk)
So the initial focus of any start-up should be starting to test the riskiest assumptions about:
The problems a product solves
Potential users who may experience that problem
The solution (i.e. proposition) to solve that problem
The amount the user will pay you to solve the problem
Once you start to understand all of the above through systematic testing with audiences, you can start to build something of value.
Every step you take with each user reduces value risk, each piece of insight helps ensure that what is finally built (your MVP) will deliver value.
The approach I take is to identify and grow a minimum viable audience (MVA) first instead of an MVP. This is the smallest audience which will sustain your product to scale – your first early adopters.
This follows the customer first, build second principle. Grow an audience first THEN think about building your MVP. People get very confused about MVPs, this should be the smallest thing you can test but you don’t have to test that with your first few prospective users – share your vision, demonstrate your passion. You are a start-up not Microsoft!
Blank explains this well in 4 steps to Epiphany. Sell the dream, inspire and excite them. Then describe a roadmap to test and learn to deliver your vision.
Spend time thinking about your target audiences, I really focus hard on these at the beginning. Use canvas, personas and impact mapping to help you understand their pain points, characteristics and desired outcomes.
Testing early can use all or any of the following:
A blog post
A script
Pitch deck
Prototype
Landing page
I like the 2 stage approach used by Steve Blank, Ash Maurya and others. First a problem based conversation and then a solution based one. Start by testing if the user actually experiences the problem your product solves, if they don’t then you’ve saved wasted time asking them about a solution to a problem they don’t have!
Use pre-registration, co-design and concierge strategies to drive early engagement with audiences.
I have written a more detailed guide on the MVA approach which you can read.
Some common objections I hear are:
But users won’t wait for me to build my product?
Yes they will, IF the problem you solve is real for them and causing them plain. Be honest about being a startup, inspire them to help co-design the answer to their problem(s).
But users won’t commit to buying my product?
Yes they will, IF the problem you solve is real for them and causing them plain. Unless you are a charity or have failed to speak to the right audience and understand the problem your product solves then they are not users you want to spend time attracting.
But my product looks immature and users won’t take it seriously
Read Crossing the Chasm and view Moor’s adoption curve, your first users are early adopters not the majority who’ll demand polished products.
But no-code makes it much quicker to code so coding early is fine
Even no-code takes longer to test with than a slide deck, landing page or simple prototype (I STRESS simple).
Of course this is a framework and based on a set of principles. Each product has its own context and characteristics. Technical products may require build earlier and there are also strategies like open source which can be used to test development based solutions (Cagan’s coverage of this is great). There are also scenarios where building a proof of concept or live data prototype is necessary to understand a problem that hasn’t been solved before and assess technical feasibility.
Which approach did/are you following with your current digital product or service? If you’d like to hear more about this approach then let’s chat, I’d love to find out more about your digital product or service.