Elephant carpaccio has nothing to do with cruelty to elephants, it’s the process where software people practice and learn how to break user stories into thin vertical slices. It came from Elephant carpaccio Alistair Cockburn. I want to use the concept to challenge your thinking. Should we as product managers be working with elephants? One of the many roles of product management can be described as creating elephant carpaccio; however, you’re still trying to eat an elephant, and I would argue most of us can’t realistically hope to eat an elephant… however big your business appetite. A better approach to eating elephants is to shrink it down to something more bite-sized, let’s think burger. You need to move away from managing demand, in this case the elephant, to managing supply. But to get there, you need to manage your stakeholders and reach an agreement.
At its core, the job of product management is one of balancing the needs of all the many business stakeholders’: customers, prospects, the market, sales, support, executives… the list goes on and on. Yet if we think customer first, a lot of these sometimes-conflicting needs can be addressed quite simply. What do customers want? They want good quality solutions that address their pains or jobs to be done, it’s that easy. However, it’s easy to forget this in the never-ending product release cycle that product managers live within.
What’s your target? Get, Keep or Grow?
First, if you buy into the concept that keeping and retaining customers is more valuable than getting new ones, this starts to define a set of variables you can use to determine how you prioritise. Of course, you need all of your business stakeholders to buy into this. This includes making sure your sales teams are not outselling and promising things that you’re unlikely to deliver in the short term or medium term.
It’s should be obvious, but too often this simple rule is not followed. You must sell what you have today, not what is coming tomorrow (its common sense right?) but as I have discussed in other articles, common sense is not so prevalent especially in business were strategy and goals are not well aligned. I hear a question, I thought selling technology was about selling a vision? Yes, it is. You can sell the vision and its important to do that. However, the requirements need / have to be managed by someone and that someone should be the product manager. Having the right product narrative comes in to play here – what’s the big problem you’re trying to fix (the villain)? What the vision for solving the problem (the hero) then you get to them and at this point, you sell what you have, not the future.
With this foundation, you can start to create a set of variables, a matrix and some metrics to help you prioritise all of the requirements, but you can’t hope to do this unless you have got control of the new requests coming in. So often I see businesses drowning in a sea of requirements – features requested by customers through sales without a clear understanding of the problem or the job to be done. We all understand the pressure of selling a solution however feature bloat is a real issue and has hidden costs across the business, more code to manage, more support calls, more sales complexity, more marketing… the bigger the elephant is, the harder the problem you’re trying to solve.
Line up your stakeholders
When we think about stakeholders in business, we don’t think about the kind we see in the classic vampire films but maybe we should. Departmental egos, unrealistic expectations and conflicting strategic priorities can soon make the product manager feel like they just can’t win. The best way to address this is to take stakeholders to one side and walk through the variables and the prioritisation matrix you have defined. Getting everyone at different levels within the organisation onside is critical. In smaller start-ups, this is less of an issue as everyone is focused on the single product vision, but in more significant business, this can be complex and time-consuming. To help you manage them, you need to be equipped with the facts, and you need to work across the business with all your internal and external stakeholders in order to get agreement on what matters. If you work in a business where everything matters, then it might be time to start looking for a new organisation. The definition of insanity is doing the same thing repeatedly and expecting a different outcome. If a business is trying to do everything then they are trying to do nothing and if your strategy is not clear, or is trying to fight on too many fronts, then you can’t win. I will cover strategy in a future article but what fascinates me is that there are only a few key strategies (market expansion, diversification, market penetration, product expansion) yet business go wrong in trying to pursue too many of them at the same time and not funding them at a level that can lead to real success.
Ratios and ranges can be your friend
Ratios are good things to use to help you get a handle on the health of your products and your product management process, in the same way, ranges are a good thing to use when you’re estimating. Building software is not like building a car where you design the components and assemble them; the goal to make each car the same as it rolls off the production line. Anyone that has built software knows there are many ways of solving development problems. Should I use an Array, Dictionary, Set or roll my own collection type? Because of this, a lot of general management thinking, much of which originated with General Motors in the 1950’s, does not help you manage digital products or development teams. You need to be equipped with the facts and you need to work across the business with all your internal and external stakeholders to get agreement on what matters. So, many CEO’s and even CTO’s or CIO’s don’t understand concepts like constraints theory or the real value of time i.e. opportunity cost. So, product managers end up at the sharp end of all of the conflicting priorities.
a lot of general management thinking, much of which originated with General Motors in the 1950’s, does not help you manage digital products or development teams
If your ratio of new defects to existing is increasing, then you have a quality problem and your most likely overloading the system with too many stories per sprint. The same holds for new support incidents to existing ones. Its’ ‘working as designed’ comments, demonstrate a breakdown in the requirements management process and / or a lack of design input. Adding new customers, if existing ones are leaving in droves, is counterproductive and especially if the new customer brings with them new requirements. This can make the problems even worse. This can be a real problem when moving to new countries with new market requirements. Using the bowling alley approach highlighted in ‘Crossing the chasm’ can be useful when making these kinds of decisions and doing them at the right time.
Herding Elephants
It’s just common sense, but if sales have been tasked with selling, then you can understand how these conflicts emerge. It’s also where looking at ratios of departments within a business can be useful, what’s the ratio of Development staff to the ratio of sales? The traditional business needed large sales teams but in modern platform business, these ratios are changing. With improved customer experience comes self-service, onboarding, social support and a range of cost-effective ways of serving customer needs. Much of which can be supported by product and product managers, but you need to make space for them in the backlog. Also, the company needs to have a focus on improved customer experience at a fundamental level, not just lip service, or it just one more thing to be prioritised with everything else i.e. a bigger elephant.
How to prioritise will have to wait for another time, the different mathematical approaches to prioritising have real value: MoSCoW, Class of service, Weighted look-ahead approach, Incremental funding model, Cost-benefit analysis, HiPPO decisions, Equity, Weighted shortest job first or CD3. Don’t get me wrong these all have a place, and I have used many different types in my past. However, the maths you use to prioritise does not get around the human aspects of managing expectations. It can’t magically make your development teams 50% more productive or increase your development budget by 100%. So, they will help you make smarter prioritisation calls, but they can’t fix management bad practice and unrealistic expectations. For those, you need to win over the hearts and minds of your colleges, and for that, you need to be able to explain why you have prioritised in the way you have and told them: what they will get, what they won’t, when they would get it and why. Get your people to start thinking burgers, not elephants.
