Customer Development with Participatory Roadmaps

When we talk about Minimum Viable Product, we often forget to discuss what it means to be viable. But it’s simple. A viable product does the thing its target market desperately wants done. The entrepreneur must figure out what is important to build in order to succeed. You can learn which features truly matter with participatory roadmaps. Participatory Roadmaps are just feature lists you ask your customers to help prioritize.

Participatory Roadmaps fit in nicely to your customer development process. To illustrate how it fits in, I’ve shared the deck I like to use.

A standard customer development deck should include

  • Questions that let you understand the customer’s business or the aspect of their life that you hope to transform.
  • You hypothesis around their pain points
  • Your hypothesizes around the solution you plan to offer
  • Screenshots of key features to discuss
    Although I’ve seen advice given by Lean Startup gurus that you can use wireframes, I find they fail to communicate effectively when shown to ordinary people. Non-developers often have a hard time visualizing what the product is from a bunch of squiggles. You should instead create mocks-ups that illustrate what you will build clearly. They don’t have to be pixel-perfect complete designs, but should look essentially “real” to your customers.
  • The Participatory Roadmap exercise
    This exercise is best done in context of the full conversation. The features gain meaning and the demo adds a reference to help the customer makes choices about what they can (or can’t) live without.
  • Limitations
    This is a slide where you share with them what you plan NOT to do, to discover if you are making a mistake.
  • Finally, see if you can get them to sign up as a charter customer. After all, it’s all theoretical until someone gets their wallet out.

For example, let’s say you are designing a syllabus maker for professors. It allows them to collect lectures, reading materials and exercises and shape them into a lesson plan. You then go out, and find some professors (the users) to talk to, as well as department heads, or whomever in charge of purchasing software the professors use (the buyers). It’s important to have both in your meeting, for they have different values and needs, and it’s critical to capture both sets of desires for success.

Next you have a conversation about what the key challenges are in syllabus design, and what your proposed solution is, then walk them through the mock-ups of your proposed MVP. It’s all a fairly typical customer development conversation so far.

Now that you have painted a picture of the potential product, you can have a conversation about what functionality is important to your customers.
This is made possible by using the Roadmap Board. It has two axis: functionality (capability) and a loose timeline: soon, later and much later. The boxes get bigger as we head off into the wonderful future. This is because backlog is always huge, what you can do in a reasonable time is always much smaller. As well, it creates a useful constraint to force your customers to choose what really matters.

roadmap-template

Now you’ll need to put your functionality on post-its. When I first learned this technique, we just wrote them on the slide and talked it through. A note taker would delete and type in features as they got moved around. I still do this when working with a large group of potential customers.

Later, I experimented with using a blank board with post-its, so the customers could physically move around features. I found this much more effective, especially when working with one to three customers. You may choose to do it in the slides, but I think moving around the post-it notes is more engaging for the customer, easier for them to keep track of their decisions and allows you to focus on capturing what they say rather than keeping up with typing out their changes.

This is a bit small, printed on 81/2 by 11 to create a simple example. I recommend printing bigger, for more features.
This is a bit small, printed on 81/2 by 11 to create a simple example. I recommend printing bigger, for more features.

 

Some tips:

  • Customers can only trade items. No adding to piles!
  • Customers should explain their reasoning. They aren’t designing your product for you, they are revealing their thinking.
  • Keep the “soon” box small; say 6 items only. You are pushing for the minimum viable product.
  • Let customers make up new features on post its and place them. The trading rule still holds.

If you talk to several customers using this tool, you’ll quickly see patterns in how they think about features. As a pleasant side effect, you may even learn the language they use. For example, the customer might talk about “tagging” being how they let people know a photo is available, a la Facebook, while you might have just been thinking of it as metadata, a la Flickr. Knowing what matters means building what will be successful.

I teach a sixteen week class on the fundamentals of starting a start-up. My students are actually using the Roadmaps pre-MVP and pre-mockups as part of their interview strategy. This will help them avoid cycles designing undesirable features.

From Henry Bacon’s blog https://medium.com/@henrybacon/update-week-of-october-2nd-357d2257ecf#.5sdweti5p
From Henry Bacon’s blog https://medium.com/@henrybacon/update-week-of-october-2nd-357d2257ecf#.5sdweti5p

I hope you try out Participatory Roadmaps, and share how they work for you. Let me know!

 


 

UPDATE 2016

Now that I’ve run this so many times with teams, I’ve figured out a trick. Almost no team starts with a Goldilocks “soon” category. They are almost always too small or too big. However, as a team it’s hard to know which, if any, problem you suffer from.

If you ask a customer if the “soon” is right and they agree, then ask them to stack rank the features, with most important on top and least on the bottom.

Then for the next test, take off the features on the bottom and move them to “later.” Repeat until customers are switching rather than happy.

If the customer says no, I wouldn’t buy that, tell them they can pick one form later or much later to add to soon. Ask how much they’d pay. If they still say nothing, or a low price, ask them to pick one more item to “soon.” When you get to “just right.” Save that version to test with the next customer.

Be sure to ask “why?” Again, you are not asking customer to choose your MVP, but rather to learn what they care about. If you think of a feature inspired by the conversations, add it.

There is no statistical significance in a test with 8–10 users anyhow, this approach is based on RITE and participatory design and follows those rules:

  • Focus on learning about customer mental models, not outcomes.
  • Capture customer language as they talk about their pains and gains. record it and a person taking notes.
  • Change as soon as your intuition tells you it’s the right thing to do. (intuition is compressed experience,; if you don’t have much experience in the space, change slowly. If you are a SME, change quickly. But NEVER stop listening to customers.)
  • Let customers create new items… after all, it’s just post-its.
  • Talk to at least eight people, but talk to more if you are still learning surprising things.
  • If participants violently disagree about what matters, ask yourself if you’ve sufficiently narrowed down your target market. Follow the lead of the person who most closely resembles who you want to sell to.
  • Always test with representatives of your target market.

My students did a dry run with each other. One group almost changed their product based on feedback. I asked them to wait until they’d gone into the field and talked to their target market. They discovered they were on the right track after all.

Talking to non-target market people will result in false negatives.