Are you performing Product Theatre?
Four (and a bit) ways to avoid the horror of playing 'Product'.
In a recent meeting, an engineering colleague of mine described a piece of work his team was delivering as, ‘Security Theatre.’ While he didn’t mean they’d built something shoddy, a conscious effort had been made to over-communicate security credentials through the design. Security jazz hands. This got me thinking about equivalents in the realm of product management. But I soon realised that, where a bit of razzle-dazzle around trust signals might help the customer and business, Product Theatre is closer to tragedy.
Rise above the tragedy of Product Theatre
Product Theatre twists great ideas into empty gestures. But you can always improvise. Here are a few sample scenes with notes on how to improve things:
1. Plans dressed as roadmaps
Plans are out, Roadmaps are in. But the weird thing is, ‘Roadmaps’ now often look like plans. They feature hyper-specific milestones, map complicated dependencies, and absolutely must be created in Powerpoint. Their maintenance often involves shifting items, ‘To the right’ and they are all too-often built specifically for project committees. Yet a true roadmap should not simply describe a series of tasks. Instead, it should evolve over time in line with your developing understanding of the market and your users. Yet many people are unaccustomed to this approach. They’ve built careers by asking, ‘When?’ and then finding ways to, ‘Push harder’. By requesting a ‘Roadmap’ they’ve updated their jargon, but not their approach.
If you’re trapped in this performance, you’re a victim of Product Theatre.
How to act: show them what they’re missing
Call a spade a spade. A plan is a ‘Plan’. But call it a ‘Current Plan’. Quietly remind people that complex waterfall projects rarely go as, well, planned. Supplement your presentations with an Now, Next, Later, Ideas roadmap (or similar) and let everyone see how you would prioritise work over time to generate strong outcomes through learning. If nothing else, when scope needs to be cut - and it probably will, you’ll have socialised your approach to prioritisation well ahead of time.
2. Analytics without outcomes
Product managers want to know what’s happening and they want to know why. They understand that strong instrumentation creates opportunities to learn, understand and impact outcomes. Combined with strong DevOps and/or experimentation tools, insight-driven improvements can accrue rapidly in a methodical, creative environment. Yet too many product managers are condemned to craft elegant dashboards designed purely to update half-interested stakeholders on what’s happening, with little to no emphasis on action. Too often, stakeholders have no desire to dig deeper or respond to learning because what budget is available after launch must be dedicated to features that missed the cut first time around.
Using analytics software to provide updates without the mandate to drive outcomes is a disappointing charade. And, often, if you stop sending the reports, no one will notice. It’s Product Theatre, and no one’s even watching.
How to act: build for yourself - and share strategically
Keep going with the dashboards. In fact, double-down. If stakeholders have lost interest, build reports for you and your team and discuss what you’re seeing regularly. Use your data and understanding whenever you present (do not email) to argue for greater agency and to establish yourself as a rigorous thinker. Many corporate cultures are stupid, but a lot of people within them are smart. If you can make strong arguments and have evidence to support your recommendations, you will gain traction over time. Just be prepared for a crawl, not a run.
3. Top-down OKRs where failure is frowned upon
A good chunk of Christina Wodtke’s amazing book, ‘Radical Focus’ advocates for outcome-based objectives in a start-up setting. But towards the end, it broadens out to warn against virulent OKR anti-patterns she sees spreading across larger organisations. These include:
Tying OKRs to performance reviews
The top-down imposition of specific objectives, and
Confusing task-completion with actual results.
Connecting OKRs to performance reviews or expecting teams to hit 100% every quarter incentivises everyone to set the bar low. It’s a sure fire way to tread water. While handing down tightly-defined objectives, or forcing the mindless laddering up of ‘results’ often crushes creativity. What’s more, if people are asked to deliver a fixed output rather than meaningful, measurable value, they will focus on the wrong things and the whole process will be redundant.
Too many companies are repackaging old-school planning as OKRs. It’s lipstick on a pig. A quarterly pantomime.
How to act: educate through OKRs
Very few people will set true stretch targets if their performance reviews are coupled to OKR delivery. But you should always look to set outcome-based Key Results that drive towards your product’s vision.
Woody Guthrie’s guitar was emblazoned with the legend, ‘This machine kills fascists’ and, while it might seem optimistic to draw parallels between a socialist folk musician and your role in quarterly planning cycles, everytime you strive to deliver value for your users as well as your employer, you nudge people towards something a little bit better. So hard as it may be, use the forum presented by OKRs to argue for a tight set of outcome-based objectives for your team.
4. ‘Agile’ squads that aren’t actually agile
Real agile squads work iteratively to solve problems. They are off-road vehicles driven with purpose. But, in many organisations, squads are just little trains, trundling from A to B against timetables they don’t control.
Every time a faux-agile squad misses an over-optimistic top-down deadline, the reputations of Agile and Lean suffer. And when engineers are called ‘resource’ and swapped in and out like Lego, product managers and designers lose key collaborators. As scrum ceremonies continue and velocity charts are scrutinised, quality and pace drops, trust in the notional team diminishes and the downward spiral continues.
How to act: cut the performance, but keep the collaboration
Of all the elements of Product Theatre, this is the one I struggle with the most, because it undervalues not only strong product-thinking but also resourceful and creative engineers. Of the wastes identified by Taiichi Ohno, the ‘Father of Lean’, the under-utilisation of talent is by far the most distressing and there’s no easy way to move towards something better without senior level support.
Despite this, I do have four recommendations:
First, keep asking your team for input and take the time to discuss why you’re building what you’re building. Collaboration will always yield results, no matter how hostile the environment - and it’s far more fun than the alternatives
Second, avoid sharing agile/ scrum reports wherever possible. As with product dashboards, stakeholders are unlikely to miss them
Third, look to carve out capacity for continuous improvement, no matter how little. Make sure you over-communicate any success derived from this work. You have to start somewhere
Fourth, if you have the opportunity to build a team, make it small and high quality. You may need to argue for more expensive ‘heads’, so you need to keep things tight. In this instance, you absolutely have to understand the finances and deliver on your promises.
Fear not!
Product Theatre is hollow and depressing. But, if you’re currently playing-out some of these scenes, don’t lose hope. For while many of us are seeing product terms commandeered and abused in service of the status quo, I believe that the value of good product practice is inarguable and is increasingly recognised. The wave is building, even if it’s still a long way from shore. Even in ‘bad’ companies, minor victories will deliver better outcomes - and anyway, you don’t need to stay put once you’ve built the requisite skills to move on.
So, the story doesn’t have to end in despair. Play your part, be pragmatic and engaged - but don’t forget that you can change the narrative over time.