Value-Driven Product Development: Using Value Propositions To Build A Rigorous Product Roadmap (Part 2)

This seven-part series is a playbook for product leaders. It describes a philosophy of product development and the nitty-gritty process details that bring that philosophy to life. It’s also an in-depth look into how we make things at, where I am co-CEO. This is Part 2.

Value-Driven Product Development: Using Value Propositions To Build A Rigorous Product Roadmap (Part 2)

Value is created by fulfilling deep desires and solving deep problems. This is what gets the people moving, what gets them to pull out a credit card, to tell all their friends, to come back day after day to consume your content and your ads, and move your little icon to their home screen and tap it more than all the others.


So it follows that your goal in a company should be to expend resources as efficiently as possible, in order to make something that people need/want/love as much as possible.

If they do love your product, they will love it for reasons. You should be constantly trying to understand and articulate these reasons. I’ll call these value propositions. And you should be planning and optimizing your use of resources to fulfill these articulated value propositions. The center of this process I’ll call roadmapping.

Obviously these terms aren’t mine. What you’ll find below are my home-brewed, and almost surely less shiny and less perfect, versions of ideas and processes that other, more accomplished people have documented at length. My aim here is just to describe processes my team at @howaboutwe has developed so that you can implement the parts that seem useful.


Defining The HowAboutWe Dating Value Propositions

I am a co-CEO at Our goal is to help people fall in love and stay in love. We have two core products: and a membership service for couples. I’m going to talk about our dating product as the example in this piece.

HowAboutWe Dating is the offline dating site. People sign up and post actual date ideas like: “How about we… people-watch in Union Square and take some Polaroids.” They connect and meet offline. It’s pretty simple and (we like to think) pretty cool.

So, what about the product makes–and will continue to make–people love it? Here’s a list of our value propositions, which are significantly adapted for this article. (These aren’t our actual value propositions, but they’re close–the real ones are proprietary.)

  1. “This product will help me actually fall in love.”
  2. “There are many people here who want to meet people like me in the real world.”
  3. “Using the product feels stress-free and natural.”
  4. “The people using this product are passionate about their lives.”
  5. “This product and the people behind it are smart and creative.”

Everything we do at HowAboutWe Dating is oriented towards making good on our value propositions. To the extent that we achieve this, we believe our target market will love our product and our business will work.

Behind each of these value propositions is a particular psychological story of desire, taste, and yearning. Other products in our space boast significantly different value propositions. If they didn’t, we’d be in real trouble because they spend hundreds of millions of dollars on ads every year.

Stated otherwise, our list of value propositions speaks specifically to our target market; not everyone wants these things. People with different values end up on one of our competitor’s sites; indeed, eHarmony, OkCupid, ChristianMingle, or Match might be better for them. Our list speaks to the desires of a particular set of people: our customers. They encounter our product and say, “Finally! I totally get it. This is for me.” In fact, if we’re doing a great job some people should really hate our value propositions; that means we’re saying something polarizing and strong, something which another group of people will love.


Value Propositions Are The Central Hypothesis Of Your Company

I believe it’s particularly powerful to represent your business strategy in user-oriented value propositions because it protects you against a problematic divide between business goals and user goals.

Our value propositions represent a carefully crafted business strategy. For instance, we believe there are enough people (market size) who will love us for fulfilling our value propositions to make a pretty big business. If we’re wrong about that assumption, no matter how adored we are by a small niche, we will fail.

Likewise, if we have many people on the site who want to meet in the real world messaging rates will be high, which in turn will drive high conversion rates, which in turn will allow us to drive more positive ROI traffic, which in turn will yield increasing revenue.


Value propositions are a theory. They are, in fact, the central hypothesis of your company. And you will prove (or disprove) and refine your hypothesis over time. The primary way you can confirm or disconfirm your hypothesis is by watching people engage with your product and carefully analyzing data about this engagement. Other kinds of research–and a commitment to observing human behavior generally–should also be included in your feedback.

The more effectively you can hone your understanding of these value propositions, the more laser-like your company will become. When you watch an Apple new-product presentation, you get the feeling like everyone at the company has their value propositions tattooed on their souls. That’s what you want.

Making good on these value propositions is basically a problem of innovation and execution: Can I come up with product designs that fulfill these goals (that’s a whole other blog post), and what is the smallest amount of time, money, and human capital I can spend to achieve this? You answer those questions with product imperatives and roadmapping.


Translating Your Value Propositions Into Product Imperatives

The first step to effective roadmapping involves translating your value propositions into what you might call product imperatives: The things your product has to achieve to make good on your value propositions. These are something like a guide for the developers. For us the imperatives would look something like:

  1. Help people actually get offline on dates.
  2. Attract many people.
  3. Match users intelligently.
  4. Foster beautiful design.
  5. Take care of the basics: site speed, uptime, multi-platform accessibility, spam filters, etc.

This step isn’t always obvious, and usually involves a series of underlying strategic assumptions. For instance, I believe that matching users intelligently will give them the experience that they are meeting people who are passionate about living full lives (even if someone else might not think that about a given person). Assumption–that’s a big one. There are a bunch in here.

Achieving these imperatives should not ideally be a matter of opinion. Your imperatives should be linked to a set of quantitative metrics. Depending on how advanced your data organization is, these metrics can be quite simple or quite complex and multi-layered. For example, “attracting many users” for us is linked to literally hundreds of customer acquisition and conversion funnel metrics, which in turn are all bundled into simple monthly “leads” goals. The key thing is that knowing to what extent you’ve achieved your product imperatives is not a matter of whimsy or opinion but of statistically significant proof.


Okay, so you create this list of imperatives. Now, I’m going to outline more granularly a series of steps–basically a roadmapping process–that will help you figure out what to build when.

Roadmapping: What To Build And When

  1. Create time and space for adding to an organized mega-list of product and/or feature ideas. We use a Google Drive spreadsheet at HowAboutWe.
  2. Add to it in a slew of ways: group brainstorming; pair work; solo work; focused group thinking on a very specific problem/question/idea; user testing; and so on. Building out your spreadsheet of ideas should be an ongoing, company-wide process.
  3. Gather an appropriate group of company leaders, probably something like: CEO, CTO, CMO, Head of Product, Head of Design, Director Of Data. Eight is the maximum number of people you want in this meeting, or it’s too difficult to make progress.
  4. Get ready to host a Roadmapping Meeting. (We do ours quarterly.)
How to Conduct Quarterly Roadmapping Meetings In 14 Steps
  1. In preparation for this meeting, write on flash cards every possible product innovation that you might pursue over the next X months (2-12 depending on your stage). These can be BIG things (“Site Redesign”), MEDIUM things (“Build a daily matches game where people can click on the people they want to meet offline”) or SMALL things (“AB Test 3 Day Free Trial”). I say “you might pursue” because if your list is super long you’re going to want to cull it before the meeting. If you’re in charge, you’re the person who must screen for whatever is just ludicrous. Try to start with under 100 items. 50 would be better. Leave out minor bugs and minutia.
  2. Intro the purpose of the meeting and how it will generally work; paraphrasing this section of this article should do it. This intro should include visibly displaying your value props and according product imperatives. You can refer back to these throughout the meeting to help focus everyone’s thinking. Ideally everyone is already on the same page about this list.
  3. Tell the group to organize all of the flash cards into 3 piles according to the effort it will take to execute them: Big, Medium, and Small. They should do this without talking unless they have questions about what something is. They might react to this “silence” thing with doubt–just tell them to trust you here.
  4. Allow any member of the group to override someone else’s decision by moving a card. If they move a card that someone else placed, they should put a yellow sticker on the card. That’s a card which is in contention. It’s fine–in fact, it’s good. (Note that in the first few minutes of this step there will be a lot of card-moving. You’ll need to subtly manage this so not every card ends up with a yellow sticker on it.) The primary goal of this step is to get everyone familiar with all the options and to set yourselves up for the next step.
  5. Discuss contentions quickly at the end of this step, and move stuff to the bigger effort pile if there is any real disagreement. No harm in that. Don’t spend more than four or five minutes dealing with these contentions. It’s critical for people to be succinct here.
  6. Tell the group that they are going to now focus on the Small Effort pile. Their job is to organize–again, silently–the pile to reflect their priorities. The question you’re trying to answer is: In exactly what order would they build the stuff listed on the Small Effort cards? Again, reference the value props and product imperatives. Again, use the yellow stickers for the most contentious cards. These stickers will be more important this time. The group should only use the stickers if they see through the movement of the cards that there is salient disagreement.
  7. Now, you’re going to end up with a prioritized list of Small Effort items with some contentions. Move on to the Mediums (without discussing the contentions from the Small pile). Repeat.
  8. Move onto the Bigs now, again without discussing the contentions from the Mediums pile. Repeat. This is the hardest group, usually. Don’t be surprised if the top 10 things on this list all have contention stickers on them.
  9. Next, return to the Smalls pile and do the following:
    • Discuss the contentions, and in that process try to get to something like consensus about a priority order in which these Small things should be done in the next few months.
    • Mark with a green sticker the stuff that you agree definitely must happen. This tactic can be used to clarify what feels critical and to deal with differences of opinion about priority order at the top, which is actually not terribly important for the Small and Medium items.
    • Actively facilitate differences of opinion to be sure the key decision makers understand all arguments and positions and can make informed, final decisions later on in this process.
    • Base the discussion and debate about priorities on both data and intuition. Ideally, everyone in this meeting is living and breathing the data relevant to their area of the organization enough to be able to speak to it on the fly. Sometimes research questions will arise out of the discussion–these should be noted and pursued later. On the foundation of a data-driven understanding of what seems most likely to move key levers and achieve product imperatives, the other aspect of decision-making will be intuition about what’s going to work best.
    • Now that your company’s best thinkers are sharing their intuitions discussing the implications of data, move them towards consensus about the smartest next bet.
    • Be sure everyone understands that the priority order listed won’t necessarily be the priority order in which things are actually built (given the complexity of product development timelines) but will only act as a guide to basic priorities.
    • That’s it–you’re done with the Smalls! This should feel exciting: Look at all these small things at the top of our Small list that we’ll tackle in the next few months and enjoy a rush of clarity.

  10. Repeat this process with the Mediums. Don’t let too many things get marked green. The target number will obviously depend on your resources.
  11. Repeat with the Bigs. This is by far the hardest and most important part of the meeting. There will likely be real–and critical–disagreement about priorities. And you will likely only be able to do a few things from this list. Possibly only 1! Take more time with this step than any others. Be careful about arriving at any decisions here. Clarify the debates. Talk about the questions with reference to your value props and building imperatives.
  12. Conclude the meeting intelligently. Thank people. Clarify next steps. Record the outcomes of the meeting in your centralized roadmapping document–including what was deemed a priority and what is a “not now, perhaps later.”
  13. The next steps will depend deeply on your product development processes. Basically you want to follow up on any research needs, finalize decisions and then get these lists into the hands of your product/project managers to make happen. And of course, you want to let the company as a whole know about your plan and find ways to keep yourself accountable to this plan. (At HowAboutWe we keep a centralized, monthly calendar of what we’re going to build. This gets reviewed carefully during sprint planning to be sure we’re on track and systematically reported on throughout each quarter.)
  14. Refine and repeat this process on a periodic basis, every few months or more.
Nuances Of The Product Roadmap Meeting
  • Depending on how your product development team is structured, you might want to do this meeting separately for mobile or for different product areas.
  • You can combine product areas and build different tracks that each get their own priority orders. The bigger the organization, the longer and more complex these meetings will be. But the same essential structure should work.
  • I’m purposely leaving vague the question of top-down decision-making versus leadership consensus and so on because I think this roadmapping process can work within a variety of decision-making models. This isn’t an article about facilitation and decision-making; it’s an article about how to organize a collaborative process of thinking about what to build when so as to most efficiently create something people love. That said, it is essential for everyone to clearly understand how decisions will be made.
  • The fundamental premise of the Roadmapping Meeting is that you trust the opinions and perspectives of everyone in the room. That’s why they are there. The CTO and Head of Design might strongly disagree–especially at first–about what’s important: site redesign versus site speed; that’s a great disagreement to talk through.
  • What you want is for people to get a bit outside their functional perspective and into a more fundamental business-as-a-whole mindset. When people are in their functional perspectives they tend to be motivated by unhelpful things like shame and pride. When they are coming from a broader perspective they tend to be better collaborators, smarter thinkers, and more effective decision makers.

Remember: Business Strategy → Value Propositions → Product Imperatives → Product Roadmap

The job of every company is to make something that people need/want/love.

This is your business strategy–and the foundation of your product’s value propositions.


Your value propositions should be translated into product imperatives, which serve as a compass for your creative processes. These product imperatives should be linked to a nexus of quantitative metrics that serve as an unflinching report card.

To figure out what to build in what order (so as to fulfill your product imperatives) you can use a leadership roadmapping process, a version of which I’ve outlined above.

The result will be a clear, relatively short-term roadmap that your key leadership helped to create, understand, and believe will lead to a product that people absolutely adore.


Now all you’ve got to do is build the damn thing.

You are reading Unblocked: A Guide To Making Things People Love, a series in seven parts.

Click here to read the next article in this series: Engineering Flow: Planning For High-Velocity Sprint

Articles In This Series

Part 1: Unblocked: A Guide To Making Things People Love

Part 2: Value-Driven Product Development: Using Value Propositions To Build A Rigorous Product Roadmap (You are here)

Part 3: Engineering Flow: Planning For High-Velocity Sprints

Part 4: Facilitating High-Velocity Engineering Sprints

Part 5: Design Flow: Achieving Breakthrough Creativity And High Yield Production

Part 6: Data Flow: Using Data to Constantly Improve

Part 7: Concluding Thoughts: Your Job is to Make Wonderful Things

[Image: Flickr user The Big Shizzle]


About the author

Aaron Schildkrout is co-Founder of (acquired by IAC, 2014). At @howaboutwe, Aaron was co-CEO and oversaw product development, design, data, and engineering