Large enterprises have lots of smart people with great ideas.  Some of these people are charming, passionate and convincing.  Some of these people are very good at lobbying for their idea with your boss’s boss.  And some of these people have the patience and persistence of a Zen priest. And then of course we have our users and our customers.  And governments and regulatory bodies (*cough* GDPR).

It is easy to get lost in the avalanche of great ideas.

Saying ‘no’ to a new idea is easier said than done. In this article, I propose a robust procedure to help product managers say ‘no’ and have that decision be palatable to those raising the idea.  Decisions which are made without buy-in are brittle.  

Working smarter not harder

My hope is that this procedure will save product managers time and unnecessary stress whilst building better relationships with your key internal stakeholders.

Discovery is our opportunity to really listen to each other.

Although this process may require more time to decide on what to build, through providing a sense of fairness we will accelerate implementation - afterall, fairness builds buy-in.

Idea overload

Looking at two economic concepts:

1. "THE economic problem – sometimes called the basic or central economic problem – asserts that an economy's finite resources are insufficient to satisfy all human wants and needs. It assumes that human wants are unlimited, but the means to satisfy human wants are scarce". Wikipedia
2. "Opportunity cost is a key concept in economics, and has been described as expressing "the basic relationship between scarcity and choice." A choice needs to be made between several mutually exclusive alternatives; assuming the best choice is made, it is the "cost" incurred by not enjoying the benefit that would have been had by taking the second best available choice." Wikipedia. 

In other words, we as product managers will never have enough engineering, data science and design capacity.

As product managers, we have a wide range of responsibilities to maximize the ROI of our products – and deciding what to build is at the core of these responsibilities.  

Theoretically it’s very easy to “just say no” and move to the next idea.  But we all know that humans/colleagues/organisations don’t work like that.  

To deal with idea overload you need an air tight discovery process.  A transparent and repeatable discovery process that will bring ‘procedural justice’ to your decision making -  whereby stakeholders understand how decisions are made and that they will be made in a consistent manner.  

So how do you objectively make evidence driven priority decisions within your discovery process?  

A discovery process which I have been experimenting with is a hack of The British Design Councils Double Diamond.  

The Double Diamond

The British Design Councils double diamond model of design is a powerful tool of design thinking. When applied to product discovery, the double diamond provides not one but two evidence driven opportunities to say “no”.

So how, exactly, does one apply the double diamond to discovery?

Groundwork

Before we get to the double diamond discovery – I recommend you do some groundwork.

Step 1: Gain agreement from all key stakeholders on the process itself. Do this with whiteboarding, powerpoint or whatever is your preferred communication medium. Propose, align, iterate and repeat.  Agreement to the process is essential to the alignment.

Step 2: Compile the strategic objectives of your key stakeholder’s function and define metrics which measure progress towards those strategic objectives (OKRs are a great tool for this exercise).  If your stakeholders don’t have this information it’s a good opportunity to build a relationship and guide them through this.  Once you have goals and metrics in place you will have decision-making framework to use in the first diamond. 

Step 3: Provide a single entry point for all ideas.  It can be low-fi (e.g. email or slack) but an ‘ideas portal’ (I use ProdPad for this) to capture critical information will save time.  Providing fields to capture additional details (e.g. Insights so far? Target users? What is the value proposition? What would success look like? Which strategic goal does this help us reach?) will prevent the need to ping pong with the person raising the idea. 

There are many tools to help you do this easily and the better tools allow the person raising the idea to track their idea without you having to manually update them.  Idea voting and duplicate idea suggestions are also great features to have (I have no affiliation with ProdPad).

Step 4: Schedule a recurring meeting every one or two weeks with key stakeholders to review new ideas.

Step 5: Schedule a recurring meeting every six to eight weeks with key stakeholders to review the outcome of experiments (i.e. ideas currently in the 2nd diamond) and/or the impact of the things that were deployed to production (i.e. the things that have made it through the discovery into delivery).

Done?  Then lets get to discovery.

Applying the Double Diamond to Discovery

Image thanks to Anna Peniaskova.

Diamond One

Applying the double diamond to discovery first employs divergent thinking to capture all the problems we couldsolve.  This is where the idea portal (see step 3 above) captures all the ideas in a structured manner.  When colleagues suggest new ideas to you at the coffee machine, in the elevator, via email or anywhere else, politely refer them to the idea portal – explaining that all ideas are created equal.

Then its time to start convergent thinking to focus our scarce resources on the problems that we think might help us achieve our agreed goals.  Review each idea against the decision-making framework you compiled in step 2 (above).  You will likely need to map ideas back to problems (as many ideas will be solutions rather than problems) and do some grouping of ideas if they relate to the same underlying problem.

Do this in partnership with your key stakeholders in the ideas review meeting (refer step 4 above).  This sounds painful, but its worth it.  Do it for your users.

This completes the first diamond. You should now have a shortlist of ideas which map to the problems that you and your stakeholders care about.  It is important to remember that to progress from the first diamond to the second diamond you need evidence - either qualitative or quantitative. Stakeholders opinions or hearsay from users is not enough. 

A key output of the first diamond is a forecast in the metric we expect to shift and by how much.  This is the bet we will try to validate in diamond two.

Diamond Two

We start the 2nd diamond with divergent thinking again to uncover all the possible solutions to solve the problems we shortlisted – some of the solutions may in fact be the ideas already suggested. We need to have at least two distinctly different solutions for each problem.

We then converge on the optimal solution through validating the potential solutions using historical data (e.g. support issues raised by users), interviews with users (sometimes including wireframes), surveys or AB experiments.  The amount of effort you want to spend should be relative to the size of the idea/risk.

This completes the second diamond.

Finally, to ensure we learn from our previous decisions we measure the actual result and compare it our forecast.  We present these at a benefits retrospective meeting (see step 5) every six weeks to discuss:

• where did we fail
• where did we succeed
• what did we learn

To learn more details on the discovery track and "Tasks within the steps" just reach out.

How do we measure the effectiveness of the discovery track?

Measure the effectiveness of the discovery track by tracking different outputs over different tasks of the process in combination with cycle time and time spent with customers. 

But the essential outputs are as follows:

Diamond 1

1. Ideas can be measured and are mapped to a metric on the driver tree
2. Improvement in a metric has been forecast 
3. Business value has been validated User value has been validated

Diamond 2

1. At least two feasible solutions to solve the problem have been identified (i.e. not just one solution with slight variations)
2. Test results (from testing the feasible solutions) 
3. Epics and user stories + other artifacts (e.g. design brief) 

Being inclusive is key – not to be confused with consensus - we involve the team of five + 2 (product, technology, analytics, user experience and quality plus operations and publishing).

Consensus on the process is key – but once everyone is agreed on the process – you are on firm ground to say ‘no’.

A final thought

Applying the double diamond to discovery does not mean to make decisions by committee. Product managers are responsible for the ROI and a key part of that responsibility is to understand our customers, users, competitors, strategy and trends - and then based on that understanding make product decisions regarding which problems to solve.

Working through a rigorous discovery process enables us to make better product decisions which are accepted by stakeholders - because building awesome software that nobody uses is not that awesome.

Just ask these guys...

Final, final thought

There are many way to do discovery and this one of them.  I am always looking to do better discovery so if you have any thoughts, want to discuss other methods please reach out.