Product Wisdom

TLDR:

• When you don’t have stakeholder buy-in, your product development risks getting delayed by bear traps, or obstacles set by those who weren’t aware of what you are doing.
• I suggest a practice, called by various names, but for simplicity let’s call it “Decision Den,” which facilitates buy-in of product developments by the right people, at the right level, at the right time. It ensures that senior management is aligned behind your initiative. It gives you the air cover you need to work at pace.
• This article includes a Playbook of how to implement the practice.

Part 1: The Problem

Digital product managers solve human problems. And usually, the biggest problem they are solving is how to give birth to an idea, not the idea itself. In other words, how can we move a new product development through the sausage factory that is my company so it comes out looking, smelling, tasting, feeling, and sounding like the thing we envisioned it would be?

The only way to do that is by getting buy-in from the right people, at the right level, at the right time. If you fail to do that, you’ll fall into the bear traps set by those unaware of what you are doing. A bear trap is an obstacle that stops progress in its tracks. It could be any significant issue – from a commercial or compliance concern to a question of strategic alignment. It always requires a decision to escape. Most bear traps are caused by people, not technology. It always, always, always slows down a project. If people aren’t bought in from the start, they won’t tell you where the bear traps are.

Both large and small companies have bear traps

In a small start-up, it should be easy to get buy-in because the organisation has a single mission, usually only one product line, and a handful of staff who can be kept up to date with a tap on the shoulder or a quick slack. But I’ve seen two big bear traps in small start-ups.

• First – lack of disciplined strategic focus. Small companies can be nimble, but that nimbleness can be its undoing if it doesn’t focus intently enough on the problem it set out to solve, and instead jumps around opportunistically. Decisions are left hanging; projects stop mid-stream. Over time, the product portfolio resembles a cluttered closet.
• Second – the outsize influence of personalities who can scupper a project through a myriad of actions or inactions. These people aren’t necessarily those who are the most senior, but those who have the most influence on the ground. They can, often unwittingly, delay development because they are too stretched.

In larger organisations, birthing an idea gets much trickier. Here you have multiple hundreds or thousands of employees, all running different product lines in different divisions. Each sub-group is vying for attention, trying to prove their growth prospects are better than their peers so they can get more investment. It is analogous to a collection of fiefdoms battling each year to be capitol of the nation state. In my career, I’ve seen the pendulum swing many times between encouraging competition between divisions to encouraging centralisation across all functions. The bear traps in larger organisations are laid when you don’t win the support from the right people at the right level and at the right time – a Sisyphean task in a company this size.

Regardless of the latest trends on corporate structures, the consistent truth for digital is “build once, deploy many times.” The magic of digital is that you can build a product with variables so that it can appear in ten different languages, currencies, and colours without the need to re-invent the wheel for each new market. Most product managers, data and tech teams will be focused on building a single platform that serves multiple markets and product lines. In a large organisation, they can easily get caught in bear traps because they can’t see across the whole organisation, so can’t anticipate the downstream impacts that their new product development might have on other parts of the business.

Stumbling on a Solution

After several years of trial and error, I started employing a practice that works to solve the buy-in bear trap in both small start-ups and large organisations. As a Chief Product Officer (CPO) and Chief Operations Officer (COO), I’ve used it in various size organisations (from 30 to over 3,000 employees, both commercial and non-profits) over the past 15 years and can attest to its efficacy. It has taken various names based on the culture of the business – Decision Den, Product Council, Product Investment Board – but the principles are the same. It is a regularly occurring formal forum of the most senior stakeholders who have skin in the game to answer the question “who decides our priorities.” For simplicity, I will call it “the Den” through this article. Its terms of reference are to:

1. Set the direction for the company’s portfolio of products or activities;
2. Allocate resources and investments that fit the strategic aims of organization;
3. Provide oversight of all initiatives.

Benefits of the Practice

The Den represents all those who should be aware of the bear traps. The impact of employing this practice are:

1. Pace– Product development pace improves because once an initiative is approved by the Den, the product team and business owner have air cover to move at pace. The meetings themselves provide a natural cadence for teams to submit their pitches and reviews. Over time, the Den builds a picture of the pace of the whole portfolio pipeline, which it can use to build a realistic view of its bandwidth for development.
2. Risk Reduction – It forces the product teams and business owners to face into the hard, risky questions at the start of the project. So, it reduces the risk of the company investing in pet projects that don’t face up to scrutiny.
3. Transparency – It increases transparency. Everywhere I’ve employed this practice, we’ve posted the agenda and minutes on whatever internal comms channels are used (intranet, slack, etc) so everyone across the whole company can see what product ideas are moving through development, and how they performed post launch.  
4. Appropriate Involvement– It gives a voice to the most senior stakeholders at the right time and in the right place. They are forced to take responsibility for their decisions and cannot hide under the “I didn’t know” excuse. If the Decision Den group approves a product development, then all members of that group must back it, regardless of how they each individually voted. This eliminates some of political manoeuvring that is common in many organisations.
5. Training – It provides excellent training for those pitching new ideas (usually product managers and business owners). They learn how to construct pitch decks, forecast scenarios, and present on their feet to a very senior audience. It helps build rapport between the development teams and the whole senior management team.   
6. Audit Trail – It builds a case history of product development decisions. The data collected over time becomes a rich source of understanding, at a macro level, of the real value of investments versus the forecasted value. It makes it easy to measure performance across the whole portfolio.

Part 2: The Playbook

Who

• People – Typically, the standing members are a sub-group of the senior executive team who have direct budget/operational responsibility for key revenue-generating functions which are impacted by product development. Usually, this will be the directors of commercial, marketing, operations, finance, tech and product functions, plus the CEO. (Usually, HR is not in these sessions.) Ask “who has skin in the game?” to decide your composition.
• Numbers – like a formal corporate board, my advice is to never have less than 4 or more than 12 standing members on the forum.
• Seniority – only have the most senior people there, don’t allow them to deputise because they need to “own” their votes. Attendance is mandatory and if they can’t attend, they can submit their votes to the administrator before the meeting.

When

• Cadence – The meetings need to be frequent enough to keep a healthy flow of projects approved and moving through the pipeline. I usually recommend starting with a fortnightly cadence and adjust from there. Like a formal board, the dates should go in the diary for the year, and are predictable, so the teams know when they must have their pitches ready. 
• Time commitment – I have found that reserving 90 minutes per meeting usually works well. It gives time for 3 pitches, voting and discussion. Pitches are timed to 10 minutes, followed by 10 minutes Q&A. Voting of all the pitches occurs in a closed door session at the end of the meeting. The meeting can always be extended if there is a lot to get through – it really depends on the portfolio flow for your business.

What

McKinsey’s decision matrix is helpful in clarifying the kinds of decisions that get made in the Den. Using the definitions below, Big Bet Decisions and Cross Cutting Decisions are the type of decisions made here. This forum isn’t for small, routine decisions, or low impact ad hoc decisions. The Den is an expensive meeting, so it should be focused only on things that have broad scope and impact. In large organisations, I’ve used the Den only for product development decisions. In small organisations, I’ve used it for most of the big bet decisions and cross-cutting decisions pitched by teams. I tend to think in terms of percentage impact. In a small business, a product idea that generates a minimum of £10,000 of promised revenue may be significant, while in a large business, they might only want to consider products forecast to generate over £1m of revenue.

How

Ideas come to the Decision Den at three stages – (1) “explore” or “discovery” stage, and (2) “build” stage, and (3) “review” stage. One key principle is that the people who are building the idea are responsible for pitching it (not necessarily those who come up with the idea). Another principle is that product teams “own” their time, so they pitch when they are ready. Usually, it is the business owner and product manager who jointly pitch an idea, with support from data and tech leads. However, that composition can vary by company and the idea being pitched.

• Discovery Stage – pitch team asks for small team and resources to explore whether an idea is worth pursuing. Often, there are many unknowns in a new idea. You need to do customer research, talk to suppliers, and run some experiments to see if an idea has enough traction to justify building a full-scale product. There are no formal financial projections at this point, just a ballpark of the magnitude of this change. This phase is usually limited to 4 to 8 weeks. Not all initiatives (or ideas) have to go through discovery.

• Build Stage – pitch team asks for full-scale team and other resources to build out MVP and launch it. This pitch does contain more clarity, including financial projections, market adoption assumptions, and time estimates to launch. Finance teams will often use the approval to build as the approval to release funds needed for the development.

• Review Stage – 2 to 3 months after a product has launched, those who pitched the idea return to the Den to share lessons learned and assess performance against its projections. If the product is gaining traction, the team may wish to plant the seeds of future phases of development during the review.

The Nitty Gritty

Before the meeting

• Administrator – You need to appoint someone to act as an administrator for the process. This role is vital to making the Den flow well. It isn’t a full-time role, but needs someone who is consistent, organised, can rally those who want to pitch, and keeps order in the meeting.
• Schedule – Create a calendar of the meeting dates. Have product managers book in slots on the dates that they chose. The administrator determines the number of slots available in each meeting.
• Communicate – The administrator should distribute all the pitches at least 48 hours before the meeting to give everyone a chance to review and prepare questions. That person should post the agenda on whatever internal comms system is used.
• Sponsor – In larger orgs, we created a principle that every pitch needed to have a business sponsor who is a standing member of the Den so that person can champion it to their peers. We found it best if business sponsor reviewed the pitch deck before it was circulated to the whole group. If that person didn’t back the project, then it shouldn’t come to the Den.

During the meeting

• Duration – Meetings usually are 90 minutes, every fortnight – but should be adjusted to your business.
• Pitching Process – Each pitch team gets 10 minutes – that should be a disciplined practice. No interruptions during the pitch. Followed by a 10-minute Q&A by the members. After that, the pitch team leaves the room. Pitches can be recorded so others can learn how to do them.
• Volume – The Den should get through three, and sometimes four pitches in a 90 min slot.
• Decision Process – After all the pitches are complete, the voting happens behind closed doors (no video recording.) There must be a clear decision that comes from the group at the end of each session. Through trial and error, I have found that using a consensus clarifying method, such as  “fist to five” works best. This technique is a twist to using your hand to vote – you raise fingers to express your support for the pitch. Raising all 5 fingers means “I love this, I want to champion it,” and at the other extreme a fist means “no way, I will block this.” Consensus is reached when everyone votes 3 fingers or more. If you are not a consensus driven culture, you may wish to consider a weighted voting method instead or another technique. Voting is essential to achieving

Decision Outcomes

To keep the the meeting tight, I usually recommend taking the votes on each proposal first before opening to discussion. This can be done by an online poll or just a simple hand raise. The voting is the heart of the practice – it forces each individual member to “own” their decision and back their views – but also to come to a consensus as a group on which product developments to support before the leaving the room.

• Green Light – Initiative approved to proceed if everyone votes 3 or more. No need to spend much time on discussion. Those who voted 3 (minor issues) will be asked to voice their concerns but the project will be approved to move to next phase and concerns will be raised to he pitching team.
• Red Light – Not approved to proceed if the majority of members vote 2 or less. That is usually an indication of strategic misalignment, or the problem is not a priority. In those cases, the project doesn’t proceed in its current form.
• Amber Light – If a minority of members vote 2 or less, those members will be asked to voice their major or urgent concerns. If further discussion in the meeting alleviates their concerns, they can change their vote. But if they are not satisfied, we will go back to the project team and ask them to mitigate the risk highlighted before they can proceed. In that case, the final approval may come only after the team has reported back on how they have mitigated those risks.
• Consensus – Everyone in the room agrees with the decisions of approvals or not, and they agree to back the decisions as a group (not revealing who said what), regardless of how they individually voted.
• Reviews – There is no need to vote on reviews, but comments and suggestions are welcome.

After the meeting

• Feedback – The admin lets each pitching team know the result of their pitch and gives tailored feedback.
• Distribution – The admin posts the decisions on the appropriate internal comms channels. The minutes always reflect the overall decision, never the specific votes by individual members.
• Audit Trail – Finance usually uses the decisions by the Den to sign off on any new project expenses.

Conclusion

That is the basic practice. Every company is different and can adapt this to fit their culture and operating rhythms if they wish to reduce their own bear traps and increase decision-making pace in their product development.

Please get in touch if you have any questions or wish to dive deeper into how this practice could work for your organisation.

MB Christie (mbchristie@productwisdom.org)