PRODUCTHEAD: The perils of pitch presentation culture

4 minute product #

---

tl;dr

Asking about a specific problem causes people to ignore the other problems they have

Make time for product discovery in small steps, not all at once

Biases reduce cognitive load for our brain when it processes new information

An opportunity solution tree is a way to externalize your thinking

---

help me out
please recommend PRODUCTHEAD to a friend
i’d be ever so grateful :-)

every PRODUCTHEAD edition is online for you to refer back to

hello

Have you ever worked in an organisation with a pitch presentation culture?

This is the kind of place where new product ideas or initiatives are pitched to peers or a panel of senior managers in a short presentation, and the most compelling ideas are approved. In my experience it tends to happen more, but not exclusively, in more sales- or marketing-led organisations.

On the surface, a pitch presentation culture seems fairly harmless. It can, however, have some undesirable consequences.

Incentive to pitch bigger #

One of the problems with a pitch presentation culture is that it’s typically a bid for funding to deliver a specific solution that will yield specific benefits: “If we build this new product, we anticipate securing 25% share of a $1 billion market in 5 years.” The approval panel grants funding and resourcing only to deliver that specific product and, in turn, that financial return.

Those that pitch successfully win the “prize” of funding, team staffing, and seem to end up on the promotion fast-track. And next time around, they have a track record of pitch success to give them a little credibility boost with the approval panel as well.

That creates a lot of incentive for pitches to become more ambitious and attractive to fend off competing bids.

Whose needs come first? #

A compelling pitch is about selling a desirable vision of the future and the means of achieving it. Often in internal pitches, this is often a compelling story about how building a new product or feature will increase growth, revenue or retention, or whatever the hot button is for your organisation at that time.

Because the people you’re trying to convince are within your own organisation, you’re probably going to choose arguments that connect primarily with their needs and desires — and by extension, those of the organisation.

Sometimes you can use this to good effect. When you have a compelling user need, you can strengthen your case by emphasising how meeting that need would also help the organisation.

The problem is when everyone starts to forget that user needs must come before those of the organisation. There is a risk that if you continue down too far down this path, you’ll end up moving the needs of the users into an increasingly distant second place.

Style over substance #

Consider two presentations of precisely the same facts, but which differ in one aspect: one person presents confidently with a neat and professional-looking slide deck; the other speaks haltingly and scribbles up diagrams messily on a whiteboard.

Which do you think would be more persuasive?

In most cases, whether we like to admit or or not, we will probably bias towards the slick presentation. It’s as if we’re subconsciously (and incorrectly) equating proficiency in presenting with authority on the topic being presented.

This little mental sleight-of-hand is called a heuristic, where we substitute a difficult question, “Does this person know what they’re talking about?”, with a simpler one, “Does this person present well?”

At university, I always made a point of printing out my essays. Aside from having largely illegible handwriting, I always hoped that the neatness of my scripts would distract my college tutor from the the dubious arguments I deployed in the actual content. I don’t know whether my ploy worked, but if it did, there was a definite limit to its effectiveness.

And so the problem with this aspect of pitch presentation culture is that it biases product decisions towards the best presenters, not necessarily the best opportunities.

Mistakes are ignored, rather than learned from #

If at the end of the project the thing ends up delivering the promised benefits, then kudos to the person who pitched it. But if not, who is going to admit to making a mistake? There’s little incentive for anyone involved to do so.

In the absence of an obvious scapegoat, any retrospective analysis would only serve to highlight a lack of due diligence (for example, failure to conduct any meaningful discovery or validation, or failure to verify the assumptions underpinning the financial model).

And yet, both the person who pitched the idea and the people who approved it often avoid any accountability. They cite factors beyond their control (“The market moved in a different direction”, “Our window of opportunity closed more quickly than anticipated”, and so on), rather than admitting that nobody bothered to check if a sufficient number of users would value this specific solution to this particular problem.

Or if the project was big and complex enough, the person who pitched it jumps ship before the inevitable denouement. (Some people have made a career of never sticking around long enough for their lengthy projects to fail, spring-boarding from one ambitious pitch to another.)

By blaming external factors, nobody loses face, the massive wasted expense is absorbed (or the startup fails), and the whole circus sideshow can start over.

Discovery before funding approval #

So why not pitch first for funding to do some discovery?

In principle this seems like a great idea. But unless the organisation already sees the value of discovery and learning (in which case, they’ve probably also avoided having a pitch presentation culture), it’s really hard to make a compelling argument to do discovery when competing with pitches promising to deliver a tangible thing with more easily-quantified benefits.

You see, discovery is partly about uncovering evidence that would discourage us from continuing:

The problem we think exists doesn’t seem to affect anyone.

The people we think have the problem, don’t.

There is a problem to solve, but everyone is perfectly happy to solve it a different way.

There is a a valuable problem to solve, but not valuable enough to justify the expense of us solving it.

All of these signals tell us not to continue, to save ourselves the time and expense of building something that we strongly believe will fail.

(If in contrast we’re seeing strong and reliable signals that there is a problem worth solving for a sufficiently large group of people, who would be willing to pay for an easier solution, then by all means go ahead. You still have to figure out whether you can solve the problem effectively, but that’s now a different set of questions to answer.)

Discovery is a means of avoiding mistakes that haven’t happened yet, so how are you supposed to quantify the value of deciding not to do something before you’ve done it? You’ve not yet got to thinking about the solution, so you don’t have even a ballpark estimate of the costs you’d be saving.

Aside from a strong signal to stop or sufficient encouragement to continue, another outcome of discovery is when there are conflicting findings, possibly because the thing you’re investigating is more complex than you initially thought. In response, you could continue by tugging on just one of the many threads you’ve revealed.

In short, another possible outcome of discovery … is a recommendation to do more discovery. This would be unpalatable in organisations that value the delivery of tangible product over intangible learning.

Discovery after funding approval #

Okay, so why not do the discovery post-funding?

Because a pitch is to deliver a specific solution, any discovery after that point runs the “risk” of surfacing new evidence which points either to the opportunity not being as worthwhile as previously thought (and pitched), or that there is a more worthwhile adjacent problem that should be solved first.

In product management terms, both of these learnings would be helpful, valuable and considered a successful outcome.

By contrast, in a pitch presentation culture these are inconvenient truths. Going back to the approval committee to say that you want to halt the delivery project or change the deliverable would look like indecisiveness. It would reduce your credibility the next time you want to make a pitch, and the approval committee would then have to justify the change in direction to their own higher-ups, meaning they would also lose face.

This only encourages confirmation bias: when people cherry-pick only the evidence that supports their predetermined course of action. It arguably also discourages discovery and validation altogether: you can’t find inconvenient truths if you choose not to look for them in the first place.

Well, I’m thoroughly depressed. What’s the alternative? #

Below I paint a utopian picture of discovery in an organisation. It’s helpful to know what you’re aiming for even if it may seem like a long way off from where you are right now. Organisations are more often like cruise ships than speedboats — they don’t change direction rapidly. Also bear in mind that no organisation is perfect at all of this, despite how they present themselves in case studies.

Discovery as a hygiene function #

Continuous discovery is regarded by your organisation as a hygiene function. Learning is considered as valuable an activity as delivery. Regardless of the life cycle stage of an idea, feature or product, the goal is to reduce uncertainty and guesswork to an acceptable enough level to give you the confidence to proceed. How you define this is will depend on how much risk appetite you have or how big a gamble you’re willing to take.

Refresh as needed #

All user research has a limited period of validity because everything is continually changing. So to counter this, the status quo is frequent and regular user research, whether to answer a specific question or to uncover potential opportunities. It is not considered wasted effort to refresh older findings to check whether circumstances have changed.

Anyone can do research #

At any given time, multiple small, nimble and suitably skilled teams are investigating possible opportunities as quickly, cheaply and easily as possible to see if they’re worthwhile to users and the organisation. Teams are not restricted to product functions, but are expected and suitably skilled to perform quality user research.

They acknowledge and minimise inherent biases wherever possible. They share their findings transparently and often, partly to avoid unnecessarily duplication, partly to ensure everyone is getting more knowledgeable, not just their own little team.

Have agreed criteria #

The product team and stakeholders have a set of pre-agreed baseline criteria that opportunities must satisfy to be considered worthy enough to explore possible solutions.

Some examples of lines in the sand you might consider for opportunities include:

• Expressed (unaided) as a pain point by at least ? of target customers
• Chosen as one of the top three problems they’d like solved in a “Buy a solved problem” exercise (variation on “Buy a Feature”)
• Most frequently asked question in pre-sales demo discussions with prospective customers
• Top three reason for calling customer support in the last two weeks

Some examples of lines in the sand for solutions include:

• Design preferred by at least 60% of users in usability testing
• Experiment variation increases conversion rate by at least 15% (if it doesn’t, we’ll keep status quo or create another variation)
• New purchase funnel increases average order size by 10% while maintaining our conversion rate

“Engaging Stakeholders with Opportunity Solution Trees: 3 Tactics to Try”, Hope Gurion and Teresa Torres, Product Talk (12 June 2019, retrieved 18 February 2023)

Having criteria like these means that only a fraction of the opportunities investigated move into prototyping and solution validation (again with real users), and fewer still prototypes end up being built for real. It is considered an equally successful outcome when teams recommend not to move an opportunity forward on the strength of their findings.

Learn about the problem while learning about the solution #

Prototype validation tells you whether your solution is effective, and can also reveal hidden nuance about the problem and the people with it. Again, teams share what they’ve learned widely for everyone to benefit.

Leverage existing research for go-to-market #

The ideas that do make it from prototyping and through production build can be launched by connecting them back to the people you originally figured out would value a solution to the problem you’ve just solved. You can develop go-to-market messaging using the most recent user research findings as a starting point, perhaps with some revalidation with users to make sure you’ve not missed some detail, or to catch evolving needs. Again, teams share what they’ve learned.

This is a portrait of an organisation that has optimised itself to conduct ongoing user and market research in a focused, not haphazard manner. People are naturally curious to learn and are really good at sharing information, not hoarding it. While specialisms exist, every effort is taken to avoid departmental silos forming, and for everyone to know some basics of conducting unbiased user research and sharing their findings.

Is this a pipe dream? I hope not.

Final thoughts #

A pitch presentation culture rewards those who pitch successfully, often regardless of whether there’s any substance behind their pitches. It also discourages the learning activities before, during and after product delivery that would help an organisation to improve the quality and success rate of its products.

I fully appreciate that many of you reading this won’t feel you have the authority or influence to change how your organisation does things at any scale. If this is you: start small. If you know you won’t get permission for discovery, don’t ask for it and do it regardless.

Start with yourself, maybe with your immediate team, even if you’ve never done user research before. Any research is better than none. Help others to get value from what you’ve learned. Strive to improve how you do it each time.

Speak to you soon,

Jock

---

---

what to think about this week

Destined to fail

A B2B product management story: on discovering problems that customers actually care about, in a very visual story thread.

Avoiding the focusing illusion

[Shreyas Doshi & Shaun Miller / Twitter]

13 ways to free up time for product discovery

Building a feature or product is the most expensive way to test it. Most product managers (PMs) are aware of that, understand the value of product discovery and are keen to put it into practice. However, they are stuck in an endless pipeline of delivery and project management tasks.

The problem with discovery: important but not urgent

[Markus Müller / Medium]

---

---

How to overcome cognitive bias in user research

Cognitive biases can have a tremendous impact on the product design process. When UX practitioners aren’t aware of their own biases, they can end up falling into the trap of faulty conclusions. A systematic error in thinking caused by cognitive biases can affect the judgments and product design decisions that team members make.

The first rule of product design is simple—be open-minded

[Nick Babich / Adobe]

Engaging stakeholders with opportunity solution trees: 3 tactics to try

I use opportunity solution trees to align, communicate, and collaborate on product discovery. The link to recognizable company goals—and the fact that it looks nothing like a Gantt chart—facilitates a healthier discussion about choices the teams are making with finite resources.

Externalize your thinking so that you can examine it

[Hope Gurion & Teresa Torres / Product Talk]

recent posts

How to influence stakeholders

Of all the topics in product management that come up in discussion, the one that’s most common and has no easy fix, framework or template is how to influence stakeholders.

Deal with the messy side of product management

[I Manage Products]

Why can’t I rely on user research from other departments?

Hi Jock,

You talk about doing user research directly with users – does it matter that the Operations and Process tracks are telling me what their users want instead?

The problem with proxies for your users

[I Manage Products]

Will platforms conquer the world?

Product managers of software and hardware platforms face unique challenges that PMs of ‘regular’ products do not.

In this panel discussion, Hans-Bernd Kittlaus discusses platform product management with Samira Negm, Peter Stadlinger and Jock Busuttil.

Or have they already done so?

[I Manage Products]

PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from a lack of bookable meeting rooms.