Introduction

I’m not anti-process. I’ve spent good chunks of my career defining and refining it. But too much can be absolutely paralyzing.

• Are you focusing more on ceremonies than the product?

• Do design thinking exercises gobble up more time than you spend with customers?

• Is your organization investing hundreds of hours documenting process? And is constantly switching it up when it doesn’t work?

These may be signs that process is taking precedence over people. Hire inquisitive talent that deeply learn the product and customer, and the rest will follow.

With that said, process has its place, but the rub is knowing which ones add value, and which ones are dogs chasing tails (although that’s cute).

I have found that many companies lack a clear product vision, often hoping they’ll stumble across it with open-ended research. Once found, the next struggle is plotting a course to get to it (and communicating progress to leadership). I’ll start off the process section with “Back to the Vision,” a framework I’ve developed with the help of some teammates. Its goal: create a living document that illustrates the path to a vision, release by release.

To be clear… I’m not providing a formula to find a vision, but more what to do when you have one.

BACK TO THE VISION

Working off a North Star or glowing-orb-in-the-distance metaphor, plotting a course for a product has some key differences to that of a geographic destination. When dealing with GPS data and known barriers and pathways, having a rigid plan is not only appropriate, it is needed. Freestyling your way across the Pacific Ocean doesn’t have consistent results (and could end up in Davy Jones’ Locker).

But product development is a bit different. You need a vision, but your destination may change or become clearer with time.

Back to the Vision™ is about establishing a big picture understanding of that vision, and then working up to it from your first release. It starts with being able to succinctly describe your ideal offering. It is important to note that others have come up with similar approaches to vision roadmaps - like Amazon with “Working Backwards” - but I think you’ll find some unique techniques in here worth your while.

1. Quick Pitch

Whether you call it a press release, overview, or vision statement - the important thing is to create a brief that describes the big idea. This is your vision, concisely stated (2-4 paragraphs maybe). The B2TV approach is more in line with the notion of an “elevator” pitch. A press release suggests a slickness of words and positioning, while an elevator pitch is straightforward and simple. It is true that your pitch must be centered on customers, but it should also be crafted with your product leadership in mind.

EX. "Manage your entire financial life in one place. Cash, wages, credit, investments - know exactly how much money you have available now and in the future. But this is more than understanding your finances, it is about full financial control, with the power to consolidate debt, change credit terms, and maximize the return on your money.”

EX. "The people who will be drawn to this product, and ultimately remain as customers, have income that allows for some savings and investments, have multiple lines of credit, and have relatively complex spending patterns." 

3. Product Plan

The product plan is a working framework for a long term vision - a centerpiece for conversation for the team and stakeholders. You can format the information however you like, but I’m going with a simple grid layout. This is not dried concrete, but wet clay you are molding through conversations, debates, and adjustments. With that in mind, make it easy to view, edit, and understand.

Let’s start with milestones.

You can call these whatever you want, but your company may have many releases, and this framework is about significant leaps in your product. A milestone, then, is a marketable major release that has clear benefits to the end customer. Again, don’t get too caught up in the exactness of your document, instead focus on pulling something together that illustrates a high level plan towards your vision.

Each section of this framework is a row within a grid. I have the description of the experience coming first - in milestones - because it grounds everyone in the basics of what you’re going for. But you can order these however you want… this is more personal preference than a rule.

Next I have the customer value. This gets into the specific benefits to the customer. There could be some overlap with how you describe the experience, but you may want to separate the two. I have some very basic examples below, but this really comes down to the difference between describing what the product can do and what it is doing for your customers.

The elevator pitch is essentially an experience description…

EX: "Manage your entire financial life in one place. Cash, wages, credit, investments - know exactly how much money you have available now and in the future.“

… and customer value description might go like this.

EX: “People can improve their financial well being, plan better for the future, and ultimately reduce their level of money related stress by having all their financial data in one place."

Now let’s look at features. This is your feature set, and should support what you’ve described as the customer value. Please note that these are product features from a customer perspective, and not technical features. Given products can have many features, I’d recommend listing the ones that most closely support the values. You may end up going back and forth on these two rows a bit, as your idea of the customer values may change, and therein the features you call out.

EX: Real time banking data from direct integration with 5 leading US banks.  

What you put under building blocks will depend on a number of things. As an experience guy, my obvious example focuses on components and the design system, but you could just as well include what it takes to build web services, APIs, a database query builder, etc. Also, I chose the term “capability” to encourage listing out higher level sets of technical features, but you’ll do what is appropriate for your organization.

Remember, the B2TV framework is meant to drive conversation and provide everyone with a simple one page document that speaks to your vision. So, don’t worry about listing out all the missing components, or have details on what it takes to build an API. Consider having chips that give you a quick understanding of the effort needed. 80% of the proposed experience will require net new components, etc. You could make the ones requiring a lot of work red, and the ones with few new components green.

Not all companies utilize OKRs, but whatever you use to set goals and what it takes to achieve them, it can fit nicely into this framework. After all, while you should center on your customer for best results, everything typically has an underlying business objective.

EX: OBJECTIVE | Reach a minimum subscription base within a year that supports revenue target goals. KEY RESULT 1 | Hit target of 2000 customers signing up for 3-month trial. KEY RESULT 2 | Deliver credit card interest rate negotiation tool (differentiator) within 6 months of launch.

That final key result moves us smoothly into differentiators. These may or may not be called out in OKRs, but should definitely be part of the B2TV framework (maybe less relevant if you’re blazing a whole new product trail). But for most products, you have existing competitors, and it is always good to know exactly how you line up against them. Maybe some releases are focused on bug fixes and industry standards, but often you should be adding features that set you apart from the competition.

This provides stakeholders and leadership a clear understanding of how you’re separating yourself from the competition - and in the context of incremental major releases marching towards your vision.

This framework is a work in progress, and I will make revisions as it matures and gets more feedback from use. Please reach out if you have thoughts or questions.