Known vs Unknown Product Framework

Article I’ve shared with my Product Team @ luxclusif.com, to improve our exploration processes from pure business-driven request to true product-led initiatives. Based on Escaping the Building Trap by Melissa Perri and some personal experience using similar methods over the past few years.

Product Development is all about navigating uncertainty until a deliverable is ready for the target customer. Closing uncertainty is the Product Manager’s job. Working on what’s closest to a definition and prioritising products and features, to allow development functions to execute on what’s right.

There are different ways to go around Exploration. Structuring Exploration methods need to be in the PM toolkit at all times.

One simple framework to navigate inside the uncertainty is the Knowns and Unknowns framework (from Escaping the Building Trap by Melissa Perri). Teams with different seniority levels can use this mental model as a tool to structure their work.

I’ve tried to incorporate in the past across teams I was either working with or leading, and the results were positive. Even when applying it to associate/junior PMs.

We should use this model when starting new projects, products, initiatives.

The model in a nutshell

The goal of the framework is all about exploring things right, starting to make sense out of the information or lack of information. Categorizing the information correctly and being aware of what to do next until you are mostly down to Facts and Intuition.

1.Known-Knowns: Identify what you know to be true about the situation, the facts you can gather from data, critical requirements, mandatory rules, regulations.

Examples:

Usually comes in the mandatory’s form high-level elements everybody talks about. (ex: GDPR requirements, Country regulations)

Usually are the hard data facts presented to you. (ex: Metrics widely available in the company or outside of it)

2.Known-Unknowns: If you don’t know if you’re facing a fact or not, you are in the known-unknown land. The land of questions, where the bulk of your work should be. Again your work is to discover and reduce uncertainty, so question as much as possible. You know information goes into this bucket when you’re able to question others (customers, teams, departments).

Tips:

Works well if you label these items as assumptions, triggers the urgency to have somebody close it.

Works well also if you label them as problems or potential problems very well crafted. Nobody likes problems, everybody likes solutions :).

3.Unknown-Knowns: Here your intuition and experience come into play. You may not know it yet, but you’ve believed in a certain truth already. Usually, the experience is the driver. Check your bias and ego and still test your intuition.

Examples:

“I’ve worked with the UI in the past, this is the right behavior.”

“I’ve worked with Order Management in the past, routing rules will need to be in place.”

4. Unknown-Unknowns: This is the space for everything that you’re blindsided to. You don’t know enough to either ask questions or do discovery upon this bucket will be empty. But the bucket exist, and the best way to go around it is to invest more in discovery and research. The surprises will come from strong research.

Examples:

That customer interview when he said a certain feature is the most useful.

That stakeholder interview when you understood you were optimizing for the wrong thing.

That research piece that made you remember a certain forgotten detail.

As a Product Manager, your or your team’s job is to focus on evolving pieces of information until they become Known-Unknowns. Meaning the focus will be on structuring and investigating the Known-Unknowns, reducing the margin of error for potential Unknown-Unknowns, and keep your Known-Knowns at check.

Meaning you will navigate uncertainty until you are in mostly Known-Knowns land. Known-Knowns is where the solution space happens. Solutions are easily built when problems are well fleshed out, meaning an execution/development team can now solve them.

On ground zero: Initiatives, projects, and ideas will start with mass amounts of information. Experienced Product Managers understand how to navigate the complexity by using mental to simplify them.

A Product Manager is successful, if he/she landed the right information into the Facts land, and can now identify what features and products should what features and products they should execute to solve a customer problem and deliver for the business.

When should I use this framework?

Every time you are starting something new. Product Managers need to be clarity keepers inside the organization. If you are exploring something new, use a framework, document, keep your references widely available. A great company thrives on clarity, and it is your mission to keep everybody on the same page.

Some examples of how I saw it being successfully used in the past:

• Revamps: Usually the elephant in the room for every company with over 5 years and changes in the business model in the middle. Yes, it will be too much to handle, but using this framework, questioning, and prioritizing will be the key to get something out of the door.
• New initiatives: It’s new and you’re doing it for the first time, it’s the perfect use case.
• Innovation projects: It’s just an idea in some heads, bringing it down, it’s your job to ensure it can go from project to product.
• Business problems: Something is happening, but you don’t know exactly what and how to solve it? Great, your problem lacks clarity. Use this framework.

What will this framework look like in reality?

This is your free space, use whatever you like. You can create the boxes and use some post-its, you can document everything in your living product document, you can use a Trello.

I’ve seen it working well in the past as tables in a confluence page, where everybody can be identified and status can are exchanged, and also saw it working well with just a google doc.

Find something that works for your organization and be flexible here, cause it’s mostly about how you capture the information. So better, more information, than missing out on information because you were enforcing a model.

Happy Product Development!