How product ate itself.

How did it all start?

Product. Do you remember how it started? I do. I was there. It was a solution to a common problem back in the 90’s and noughties. Let’s remind ourselves how it used to be.

Someone senior in the business would come up with some numbers that needed to be chased. Some other people would be bought in to analyse how to get there. Laboriously and over a loooong period of time they’d write a ginormous Yellow Pages sized requirements doc. This would then get lobbed over the wall to the developers who would try to interpret what on earth was going on as they built against it. The developers wouldn’t be able to ask questions of the authors of the document because being highly-paid consultants they'd left with sacks of cash ages ago and were no longer about. The testers then got blamed for the delivery being late and not fulfilling the original ask from years ago because they were the last to touch the code.

The dotcom boom changed the way we work

The dotcom boom changed the dynamics of this. Suddenly, via the internet which was new to most people at the time, paying customers wanted new services, fast. The tech and ‘solution’ landscape was changing month in month out. Companies that were winning were the ones that responded to changing customer demand quickly, provided secure confidence-inducing services and made it easy for customers to buy things.

Let’s think about those three things a bit more.

• Responding to change was largely addressed with by process change, enabled through Lean and Agile practices such as XP, DSDM, Scrum and Kanban. Agile ways of working was and remains about people interacting efficiently.
• Fast, secure offerings were down to new technologies from Enterprise Java Beans (remember them!) to simply making more of https amongst other things. Even now, technology changes fast, but that’s cool as for the time being the software written still does what we program it to do (though AI will change that).
• Making it easy to buy things or interact with customers was still in trouble though. How do you get away from unwieldy requirements docs or some mad-lad with ‘Senior’ or ‘Executive’ in their job title leaning over your shoulder and just telling you what to code up? Well, you needed someone or something between the crazies spending investors’ money and the people building the ‘solutions’.

And that solution was ‘Product’. And it was good.

Product becomes a thing.

So now we’re probably in about 2005 or something like that. XP is the agile domain of the nerds and DSDM is the leading mainstream-ish ‘agile’ delivery framework if you can call it that. Ken Schwaber , Mike Cohn and the gang are striving hard to bring Scrum in from the mainstream and in the UK at the time pioneers such at Mike Altendorf who led the sadly defunct Conchango and Colin Bird who led the Agile Coaching team within it are getting Scrum embedded and working with organisations who want the edge (and got it).

For me Scrum was a game-changer. One of the reasons is that one of the original roles in Scrum was a ‘Product Owner’ [1]. This was the first time that I’d ever really seen a role that sat between the Execs and the delivery teams who’s job it was to filter the zany ideas from stakeholders and customers and get them in to a well-formed and prioritised list (a backlog), actually work.

It was simple. It was elegant. It was about to get abused.

Product begins to get wrecked from the start.

The first thing that happened was that ego got in the way. Instead of owning, by which I mean being accountable and responsible for product requirements which represent the needs of the customer and the business through the content and ordering of the backlog, people wanted the word ‘manager’ in there. In my experience this is not about managing the product, but more because getting the word ‘manager’ in a job description gives individuals some kind of feigned impression that they have control, power or dominance over other people. Fake superiority – yay! That always ends well. /s

So now we have Product Managers. Fine. Not a hill to die on.

What we don’t realise at this point is that we really have the beginnings of the career Product Manager who specialises in the role not the customer. You see originally Product Owners were more often than not Subject Matter Experts (SMEs) from around the business who would do their day jobs 90% of the time and then we’d help skill them up in Product Ownership techniques to help us get the backlogs ship-shape and interactions with the developers smooth and productive.

Scrum Masters get overlooked.

Getting the interactions, insights and requirements right for product development is hard. A good Product Owner is out there doing a busy job. So how did we get their time? Well, the Scrum Masters (remember them?) would do their job by being head organisers / coaches and guardians of process by making sure that Product Owners / SMEs were in the right place at the right time. They’d coach the SMEs about the role of product to the point they’d be useful and effective Product Owners and could work directly with the Engineers, Designers, Testers, Business Analysts etc., to make sure we were building the most valuable things for the business and customers in the right order.

Scrum Masters (many called delivery managers these days) are grossly over-looked even now. Another topic for another post, but ignore a good Scrum Master at your peril.

?

Product becomes an industry in itself.

What do I mean by this? How about an example? Recently I went to see an old friend who has recently taken a new job as CEO of an around 200 person-ish organisation. She inherited a “Product Department” which had sixteen, yes SIXTEEN Product Managers of varying experience in it. On being asked, my first reaction was “what the hell do they all do?” - the organisation only has two products and if you squint hard enough it’s really just the internal and external facing part of the same software solution anyway.

The take-away issue with this is that ‘Product’ only exists to represent the needs of the business and the customer and make decisions about it in a timely manner. The sixteen people in this instance have the job of defining problems for the developers to solve - meaning they are just a problem generation factory at best and a powerpoint generation factory at worst. And on top of that they are really expensive and inefficient.

What happens here is the Product Department simply generates crap on an industrial scale that ends up being dumped in the backlog, Jira or other tool. This bloat slows things down further (remember limiting work in progress, anyone?) resulting in senior people by-passing the slow inefficient system to get something actually done …and then we’re back to all the “agile doesn’t work” posts which are posted daily here on LinkedIn.

?

So where are we now?

Well, we’re in a place where organisations are delivering slowly if at all because they have a soup of not-really-that-experienced-or-capable ‘product professionals’ who aren’t subject matter experts in anything the customer or business really needs.

Instead, many of them have become amazing qualification tourists who have all the badges and certificates you could ever want but little useful value-add for the organisations they’re working for. Often the Scrum Master or Delivery Manager roles which helped organise and oil the wheels of progress aren’t there as they’re undervalued and mis-understood. So ‘Product’ in many cases has become an unproductive cost, which is sad, largely unnecessary and hurting your business – especially considering the good it can do if done well.

?

What can you do?

• Not overreact, this isn’t a call to brazenly slash headcount. But it is a friendly nudge to look at your Product team and question what is going on.
• Remind yourself of why Product as a discipline exists. Consider how it can add value. Make sure the Product team has a clear Product(s) Vision that aligns to the Company Vision and supports your strategy of how to get there.
• Consider how you might rationalise your product folk behind genuine product entities. You might actually only have one – or only one that needs working on at any particular time. Being Product-Led is worthy, if done well.
• Implement the original intent of the Product Owner role, as having the autonomy and accountability to truly lead each product, represent the needs of the customer and the needs of the business.
• Ask yourself if your Product Owners are getting out there and learning about customers (whether internal or external) or just being Jira jockeys. Are they getting stuff done and getting it done right, or are you just creating PRDs and requirements three levels down from where you used to?
• Think about who in your business can help your Product Owners. One simple top tip here is that if you have a customer service department ask them what the customers want – they will be able to tell you lickety-split leaving little room to the imagination.
• Remember that a good Scrum Master, (or agile delivery manager if that’s your thing), can really oil the wheels of progress and productivity. Get them to remove the work from the Product team that isn’t researching and codifying customer need. If you have written (good) Scrum Mastery off in the past challenge yourself on that.
• Remember that ‘Product’ as a discipline is about being the ‘Guardians of Value’. They represent the needs of the customer and the business. Data Scientists, Business Analysts, UXD and so on often form part of that and make an awesome Product Function when they work together properly.

?

TLDR;

The discipline of product came about for a great reason and it is an asset for any company that delivers software product. But in many cases it’s got out of control as its become a fashionable and bloated industry most businesses can’t afford, thus getting in the way of delivering value a lot of the time. I suggest in many instances reining it in and bringing a bit of focus to the original intent of Product may actually help us get more done.

Comments are open. Let’s do this!

?

[1] It’s worth noting to Ken Scwaber’s original paper from 1995 that he used the phrase Product Manager. By the time the Scrum Alliance got round to codifying the Scrum Guide v1 in 2010 it was Product Owner for the reasons stated within and has remained so ever since.