Design Thinking for Product Launches: Minimal Viable Discovery

“If you are not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman, Co-Founder LinkedIn

This quote extends to every aspect of business. From your hiring plan, to your product releases and even your sales methodologies, the first step should always be: produce just enough to understand the next step. From there, collect feedback and iterate. In other words: Action Produces Information.

What is the bare minimal asset you can create in order to understand the pain and validate the solution? I call this “Minimal Viable Discovery”.

Several years ago I immersed myself in the practice of Design Thinking. I dunked my head in the Kool-Aid, devouring every piece of content from IDEO to Frog. I even taught Design Thinking courses to others.

These principles are core to every aspect of a business: develop a hypothesis, start with your users, learn, iterate, and grow.

After building and launching dozens of products over the course of my career as Software Engineer, Product Manager, Co-Founder and now Go-To-Market Lead, I feel equipped with enough information to propose a “release framework”.

Here is my attempt at applying Design Thinking principles for collecting feedback and iterating within a Minimal Viable Discovery product launch plan:

Minimal Viable Discovery; Product Launch Feedback Loop

1. Define

We need to first understand exactly who is important in our feedback collection lifecycle. Not all opinions are created equal after all.

• We first define our Ideal Customer Profile. Which personas should influence our roadmap the most? Certain characteristics should be defined such as industry, size of company, existing solutions, etc.
• How do we plan on collecting their opinions? Is it a Jira board? Trello? Raw notes that get reviewed regularly by internal stakeholders?
• Define your release cohorts. What batch sizes will be interacting with the product? How long will each cohort last? How will the cohort expand over time?

2. Hypothesize

Everything should be treated as a hypothesis until it’s validated by true user interaction. There is a strategy called The Mom Test that is core to understanding the pain. Your hypothesis assets will be used to extract the core pain/value via Mom Test-like questions.

• What minimal viable asset can be used to conduct information-based discovery? Often this is a demonstration, but can be a tutorial, documentation, diagram, or even a simple write-up.
• Who are the team members that will be conducting the minimal viable discovery via the above assets? Distribute and enable these team-members on these assets.

3. Discover

User discovery is a skill I’ve been perfecting over the course of the last 3 years as a Pre-Sales Engineer at MongoDB. It requires a balance of active listening, technical acumen, and leading the discussion in an incredibly nuanced way. The best CEOs, Engineers, and Sales-people are all well suited at pain-extracting discovery.

• First we need to understand what the user is doing today. What is their “pre-my-solution” state? Often this takes the form of a data-flow diagram and/or simply a documentation of processes.
• You then overlay your future-state solution with that “previous state” diagram and/or process flow.
• The delta between the previous state and your future-state is your Required Capabilities, in other words: what requirements does the user have in order to get to that future-state? You map your capabilities to these requirements. We need to build out this list of Required Capabilities, it is what will be used to sell, market, and enhance against validated Product-Market-Fit.

4. Formalize

We then take the lessons from our discovery in the form of newly-documented Required Capabilities, and build out “proofs” in the form of demonstrations. Basically, answering the question: “can you support this”?

• Every Required Capability should have its’ corresponding product feature demonstration, these are called “proofs”.
• If the feature does not exist natively (which should always be the case for a growing product) then hacked-together workarounds should be developed. These workarounds can take the form of a Zapier workflow, a tutorial, a blog post or even a Q&A document. These are powerful mechanisms of triaging validated capabilities against the product roadmap.
• How are the users finding the demonstrated native and non-native required capabilities proofs? Funnel that feedback in the collection methods above (jira, uservoice, slack, salesforce, sales). If we’re finding a ton of users (internal and external) are asking similar questions via Slack, Teams, etc. then a proof needs to be created.
• It’s up to you as an organization to remove any friction for submitting feedback. In other words you must democratize feedback submission.
• Collect and document the most common use-cases for your solution against the pre and post states.

5. Engage

Now that we have documented our exhaustive pre/post states, Required Capabilities, proofs, and use cases it’s time to scale our efforts across the sales organization and continue into implementation.

• We need to teach the Pre & Post-Sales teams about the assets and processes defined above. For example, what keywords from the customers’ mouth would prompt them to think “this required capability”?
• An early product release should imply incredibly high-touch post-sale implementation. Your product is too nascent to have users interact independently of your experts. Each post-sale implementation should have well-documented “sticking points”. Where did the user get tripped up?

6. Improve

Now it’s time to take all the findings above and conduct formalized retrospectives. What went well? What could’ve gone better? The lessons should be used to enrich for the next round of releases.

• Formalize your opportunity retrospective processes. From pre-sale and post-sale which required capabilities were the most effective? Which proofs could be improved?
• How did the user find usage of our product? Document them into Proof Points that can be used either internally or externally.

This is my attempt at consolidating the feedback collection and iteration process of releasing a product. It’s not the end-all-be-all approach, but it’s worked quite well for me at my previous jobs and I’ve tuned it with every release.

In parallel with the above, you should always meet users where they already are and remove any friction for usage and collecting feedback.

To learn more about me or my work, please check me out: ethan.dev

Obligatory:

Opinions stated here are not reflective of my employer’s.