The Creator Myth

the woods would be very silent if no birds
sang there except those that sang best

Probably the most important change to tech delivery, in the last five years or so, has been the rise of Product Management. As a discipline Product Management has been around since way before we had software products and services that needed managing, but I am talking here about the relatively recent named team on the org chart, often led by a Chief Product Officer (CPO) where Product Managers, as opposed to Project Managers, or scrum style Product Owners, interact with tech teams to get things done.

You know, that new group, often referred to as the team through which all change must go.

This is not a rant about Product Management as a discipline. Far from it. I am a wholly enthusiastic supporter of the teachings of people like Marty Cagan, Melissa Perri, Teresa Torres, John Cutler, etc.

And my rationale is simple: I have lived through some amazing advances in tech. We have tools and processes now to enable us to update our products with new features many times a day. Our problem is less about making change than is it about making good change. Without the benefits of Product Management Thinking, we could easily kill our businesses in just a few releases. Looking for product/market fit, making customers happy, solving their problems, understanding the space our product operates in and making money doing it are critical to a business’s success.

But, like agile 20 years ago, many businesses are struggling to understand how to “make product work”. I think it’s fair to say that introducing product thinking into a business that’s not properly discussed what it means for them, and how to deal with it when it does show up (let alone find the people who understand product because, just like agile, there are way more people winging it than there are people who know how to do it), actually makes everything worse.

I think Product Management right now is failing so badly that it’s in danger of being discredited.

Is that contentious? I don’t think so. I don’t even think it should be surprising. Agile was the hottest thing in town for years and went the same way. That’s why Dave Thomas declared it dead in 2015, instead preferring to work with agility. It’s 2023 and I’m not sure it’s safe to say that even half of the organisations that rely on software for their survival are working with agility. Lobbing product management on top of half-baked agile is a recipe for disaster.

But oh lordy, when it does succeed it’s just the best way to work. And that’s an important data point: it can work (I’ve seen it) and, right now, even though it often feels a bit scrappy as you find your feet, it’s most definitely the right direction for a tech-driven organisation to shoot for.

The twin joys of a) feeling like the work you are doing has genuine value and b) that everyone knows what’s being done, what’s not being done, and why, add a real zip to coming to work.

What Good Looks Like

First of all, you absolutely need to get some basic structure of agile delivery in place. You don’t need perfection, but you do need some sense of flow from ideas to production delivery, that doesn’t have too much latency in it. What I mean by that is when someone (appropriately qualified, which we’ll come to in a minute) raises a new feature idea it needs to be aired, discussed, maybe parked, maybe trialled in some cheap and quick manner, before it potentially joins the queue for actual delivery.

Ideas should not hit a wall and owners of ideas should never feel like they don’t know where they stand.

However, we should be clear that, in this flow of ideas, many (most) of them will never be delivered. It is survival of the fittest (most valuable) only. Most of the herd will die. And to maintain flow they must, sadly, die quickly.

And this is the root of the problem of implementing product management - the company culture (in both the wider business, tech and product itself) has to ruthlessly pursue ideas which have these properties:

• There is a high probability (backed by data, not opinion) that new features will affect some positive change in the world (e.g. customer behaviour).

• The context of new features is well-known to everyone required to make it real, especially the engineering team (i.e. they were all involved right from the beginning).

• The data behind new features is transparent, shared, prodded, and argued about. It might be analytics data, data from AB tests, fake door tests, customer interviews, etc. but there is data, and it’s freely available.

If you don’t have this in your organisation then you are wasting money having a product team. You might as well have a PMO and add features using traditional projects. There is no shame in recognising that. Product Management will come when the culture is ready. Work on a delivery model that’s based on flow and agility and data and product won’t just come, it will be needed.

And when you are set on embarking on a product-centric journey, it’s worth knowing some of the common pitfalls. In my experience, there are four which I shall call Misaligned BAU, Product Team not Product Working, The Big Override and, my favourite, The Creator Myth.

Misaligned BAU

I’m going to define BAU (Business As Usual) change as small, isolated, change requests that can be done by a single developer in less than a day. That’s my arbitrary definition but it’ll do for discussing this anti-pattern.

BAU work doesn’t stop when you adopt product management, so there does need to be a mechanism for people to report issues and track their progress. The mistake is a) having a team that “does BAU” and b) assigning change to BAU when it does not fit the definition (usually as a back door to avoid following a process that feels unwieldy).

BAU is a Team

Product-centric delivery means chunking up work, and the organisation, into product buckets.

For example, if you run an e-commerce website, then one of your product areas would be some form of Product Catalogue. In the spirit of Domain Driven Design and (possibly micro) service-based architecture you would then have a team that looks after that product area.

And BAU work for that area would go to that team alongside product-driven work for the obvious reason that having all the work for the product on the same table makes for rapid transparent prioritisation (therefore data-driven flow and agility).

Big (product) change and small change belong together because there’s no pre-destined correlation between size and value. It’s a mistake to think BAU work is low value. Some of it is huge value for negligible work.

BAU is a Back Door

Sneaking change into BAU is understandable when the alternative feels like a process that’s not based on data-driven flow and agility. But just because it’s natural doesn’t mean it’s helpful. There are two huge issues created by a BAU Back Door. The first is the BAU backlog becomes massive quickly. Far more than the team could ever hope to deliver. Which in turn de-motivates them and annoys the change owners. “Your ticket is number 145 of 213” one day, followed by “It’s now ticket 164 of 319” does not feel like transparency, even if it is. Even a periodic cleanse of old tickets doesn’t help, because that leads to “Your ticket has been deleted” and they just build back up again anyway.

BAU as a Team and Overloaded BAU are product management delivery smell that suggests the process is broken, too many items are being approved without data and change is not being managed in a product-centric manner.

That is not to say all change fits the product model. Having a small change team with a healthy, small, kanban-style board they can rapidly chomp through makes a lot of sense. But the product team has no say in this workload because it’s not product based. Management decides the investment percentages and both mechanisms work in parallel.

Now that is often a contentious point. Because a phrase I hear a lot in all organisations not long after a product team has appeared is “Product decides X” - Product decides what features get added, Product decides priority, Product decides the business case, and so on. All false. Product decides nothing. To get to the bottom of that we need to examine what Product does.

Product Team, not Product Working

So you’ve got agility and flow sorted and you have data dashboards everywhere. Now you have what they call a high-quality problem. Which feature ideas should go to development?

A good thought experiment for implementing any new role is to itemise all the problems you have without it (assuming all other roles do their bit) and when you can identify a stack of them that are tightly coupled enough to be done by one team of people, you’ll know what they do and why they exist.

If you have agility and flow, then you already have autonomous cross-functional teams. And, to be clear, autonomous means a team that has a well-defined set of goals (business outcomes) and is pre-approved to go after them in any way it sees fit. Cross-functional means the team is comprised of everyone invested in the outcomes, which can mean finance, marketing, sales, customer service, etc. Not just engineers. And by comprised of I mean they attend stand-ups, retrospectives, planning, are on the hook for delivery, share the responsibility when things don’t go well, and bask in the glory when things do. Delivery is not the preserve of the tech department. The team lives and fails and succeeds as a unit.

Product Thinking

The team is a mini self-governing powerhouse of awesomeness. Except they don’t know which feature ideas should go to development. Well, they do, because they talk all the time, but people have different focus areas and tasks outside of the team and a good product hits all the right spots for the customer and the market and contains no features that don’t. No wasted engineering effort. No wasted time. Agility and flow. Someone needs to bring this targeting perspective to the table. Not so they can decide, but so the team can decide.

This is one of the biggest misconceptions about Product today. That somehow Product are ‘in charge’. As Marty Cagan said: product managers do not do business cases, requirements, project management, marketing, pricing, promotions, positioning, messaging, or product launches.

They contribute to these things (with the rest of the team) and help the whole team come up with products (and features) which are valuable (customers will pay for it), usable (customer can work with it), feasible (deliverable with the team and tech we have) and viable (deliverable within the organisation’s constraints of budget, time, capacity).

A lot of the confidence for this view will come from market research, customer research, analytics, running experiments that are cheap and quick to count ideas in or out. There are no certainties. It’s about getting enough data to quickly decide what to do next. Agility and flow. Not control.

Product Managers that don’t improve the quality of the output from agility and flow (vs not having them) are a delivery smell. The fix is to reset the role scope and make sure any non-product responsibilities are managed by others. All roles should be doable by a human, not a unicorn.

Product Delivery

Project Delivery comes with Gantt Charts that show when projects start and end and what milestones are expected along the way. Products are born and retired, but they don’t fit on a Gantt Chart. They don’t have milestones in the same way. The aim is not to hit a date but to achieve an outcome. Yes, everyone wants everything yesterday, but if you can’t have that then the best alternative is to have it as soon as is reasonably possible (as long as it remains valuable, useable, feasible and viable). The outcome with the highest business value doesn’t need estimating, because it’s got the highest value of anything on the table. Drawing up a Gantt Chart for something you have to do takes time away from doing it. Agility and flow.

This is not to say a business doesn’t need to know what it’s doing, or have an idea of when things will be done, transparency is key, but the activities of talking about work should not affect the ability to do the work. And unlike project-work, product-work flows continuously. If it comes with a project plan, it’s not product delivery.

The Big Override

Installing a product team requires trust. Organisational trust and team trust. A common mistake I see is companies moving to product working because they think somehow product managers will make delivery faster, or make due dates more reliable when that’s not part of the role at all.

Organisational Trust

But then when they do have product managers who bring the data to the conversation they override the team’s choice of what to build. This is Autonomy Theatre: bragging outwardly about how empowered your teams are, but still stepping in to tell them what to do when politics, seniority, perceived emergency, or just general arrogance arises.

It’s the fastest way to start to demoralise a team and start an exodus. Now, obviously, there are times when plans have to change, but it’s perfectly possible to do that with the team using existing process. Set the desired outcomes and explain them and, when things change, explain the context and discuss how the outcomes (not the how or the what, but the why) might need to change. And be prepared to make that a two-way conversation.

If the team are working on something they don’t believe in or understand, it’s a delivery smell. What follows will be late, half-heartedly done and not meet expectations.

Team Trust

This trust needs to happen at the team level too. If the individuals don’t understand what value the Product Manager brings then they won’t trust them. They may do the work but what you get is a kind of intra-team version of quiet quitting where tickets are processed but there’s no sense of ownership or pride and, as with organisational trust, the outputs are generally disappointing.

The Creator Myth

Our final smell in this exploration of implementing Product Management is the Creator Myth.

In the same way that stand-ups became an unconscious vehicle for making micro-adjustments to software delivery, when it’s done well, product delivery is almost invisible. It just happens. We talk, make choices, move on. I want to say it’s boring, but it’s not so much boring as predictable routine. The content may be exciting and motivating, but the rhythms are not. It’s not flashy or showy.

There’s no Steve Jobs. No one is creating. Every step is an iteration from the last.

Just over 10 years ago, Apple and Samsung got into various legal battles about the design of their phones and tablets. The details aren’t relevant here but, during the documentary disclosures, it came to light that Apple, contrary to everything they’d been saying for years, is really, really, into market research. And Apple was not happy

Steve Jobs was not the world’s greatest product manager. He was an amazing marketer who wanted to curate the myth that Apple is a magical company that builds great products because of its magic. And why not? I mean it’s a great story. I’m happy to play along because I love my Apple products, but it’s very very dangerous to try and replicate a myth as a delivery approach in your own organisation.

Apple’s product development process is extremely iterative as you’d expect. Their product ideas are not new but borrowed. Any greatness is iterated.

Product Managers do not create, because no one creates. Annual portfolios of delivery outcomes are set according to the business strategy and budget and those outcomes get picked up by autonomous teams. Those teams generate (rather than create) better products and features by chasing down the value against those business outcomes. The exec team sets the target areas which, once in a while, will result in new products. If the target areas are right then product delivery can be magical. But it’s culturally very hard to just set targets and let the process take over. The desire to create is strong.

I know I found it hard to get used to until I realised I had more than enough work to do helping teams stay aligned, both to the overarching goals and to each other. I don’t think Product Management has all the tools yet. Agile became quite a different endeavour once support for continuous delivery became a commodity. But the ideas are sound. It’s mostly a case of hiring the right people and setting them free. Autonomy is the cornerstone of agility and flow. As Steve Jobs himself said

It doesn’t make sense to hire smart people and tell them what to do; We hire smart people so they can tell us what to do.

Notes

• The subtitle is lifted from Shakespeare’s Sonnet 59 which has, in summary, been aligned by Thomas Foster to the notion that “pure originality is impossible”

• The photo, taken by the author, is of a grave in Dundee’s famous The Howff burial ground

• The photo caption is a quote from Henry Van Dyke