#prodfun - Setting Product Direction

How do you determine product direction? This is a question I'm often asked when I get a chance to mentor the next generation of product leaders. And this is the question I was asking myself just over 15 years ago but with a slight twist. How do we set product direction REALLY FAST? And how do we make that a repeatable and scalable process? I've successfully implemented and refined this process at FamilySearch, Adobe, Ancestry, Vivint, and Lucid Software.

Out of necessity, I created the initial version of what is today called Product Fundamentals - or #prodfun for short (Thank you Jamie Bergeson Lyon for coining the hash tag). This was before I had even heard of the concepts like design sprints or other similar time-boxed approaches. Presumably many people in the industry were asking the same questions I was about how to do this better.

What is Product Fundamentals? #prodfun is a scalable and repeatable way to set product direction. Scalable in that it works for large questions like what should our new product or hero feature set be or small questions like how should we approach this epic. Scalable in that it can span many teams concurrently or just one team.

What Product Fundamentals is not. #prodfun is not a discovery process (though I have integrated this into the process at times) nor a validation process. It presumes that there is a lot (or at least sufficient) knowledge available to feed the process. And it is often beneficial to follow the process with validation techniques to reduce the risk of the proposed direction.

The process is a time boxed approach that gives teams a couple of days to work through the following phases to create specific deliverables, review them and get feedback from their peers (in what I call a Stand and Deliver session), and push on to the next phase. The Stand and Deliver sessions are critical - they are the flywheel of the process but and are best when there are multiple teams working concurrently on the same or similar questions. Here are the phases.

Kickoff & Context (day 0). Provide the team(s) with all of the inputs they will need to set product direction. Context on customers, market, business, and product performance.

Jobs, Needs, Gaps (days 1-2). Identify the jobs, needs, and gaps of the target customers. Then tell this in a visual story format - the problem story.

Value and Capabilities (days 3-4). Describe the value that would result if the problem story is resolved. This is not a description of how the pain is resolved, but a description of what value would be created if the pain were resolved. Then identify the implied capabilities - the capabilities that must exist in order to create the value.

Possible Solution (days 5-6). Identify possible solutions to the problem story. Include sketches and mockups. Tell this in a visual story format - the solution story.

Value Chunks & Competition (days 7-8). Create a value chunked roadmap (chunks of value that would make sense to communicate in the market). Identify the best competing alternatives.

Here's a link to a Lucidchart diagram of the process including links to other resources and some Pro Tips.

How do you set product direction? What are your best practices?

======================

Now some special thanks to people that helped refine this approach to product over the years.

Special thanks to Ron Tanner and Grant Skousen and many others who were the original guinea pigs for the process. Thanks also to Vicky Thomas, Anthony Morelli, Jarom Chung, John Dilworth, Kenny Freestone, JD Nyland, Bret Gundersen, Chris Wareham, Matt Snyder Jamie Bergeson Lyon, Phillip Badger, and many others that have helped refine this process.

One final call out, thank you to Michael J. Lanning, for the book, Delivering Profitable Value, which had a large influence on the thinking that inspired this approach.