Product Management on the London Underground

Seen in the carriages of the Tube - broad scatter-gun advertising to pretty niche audience!

Prioritising the Product Backlog

Louise Cantrill (Head of Consultancy at Tarigo and one of the sponsors of the Cambridge Product Management Network) writes an excellent article on the various Methods to Prioritise User Stories.

All prioritization techniques attempt to rate all the possible projects. Doing the high value / low cost projects are a no-brainer, of course. And you don't need a fancy model to tell you these big wins from the rest. It's what happens when you've done all the obvious ones - that's where it gets hard.

These techniques are supposed to make a comparison between big scary projects that are high risk, tie up lots of resources, but create new exciting opportunities versus lots of small improvements that are (relatively) quick to realise, benefit a sub-set of customers or make small, incremental improvements in consistency (for example).

All of these techniques have their advantages and will give you a ranked order of projects, based on biases that each technique injects. I have delivered my own prioritization technique - see Feature Prioritization and Roadmapping.

Whatever the results, you can view them as militant instructions or mildly useful recommendations. Nothing trumps a CEO who has just had a berating from a key customer or his dreamy conversation with a visionary at a conference!!!

1. RICE Scoring

Reach	the percentage of users or customers who will be affected by the feature, or initiative.
Impact	an assessment of the potential value or benefit that the project or feature will bring to the users or the organization.
Confidence	The team's level of certainty in the Reach and Impact estimates.
Effort	Effort quantifies the resources, time, and complexity required to implement the project or feature. It considers factors like development time, design work, testing, and any other resources needed. Effort is typically scored numerically, such as assigning a time estimate in hours or days.

RICE score for a particular concept = (Reach x Impact x Confidence) / Effort

I like this approach because: it appreciates that some features only benefits some customers. Without this, product development has a bias towards only doing features for 'squeakiest wheel', which is often the biggest customer.

2. MoSCoW Method

Must-Have	User stories that are essential for the project's success.
Should-Have	Important stories but not critical for the project's immediate success.
Could-Have	Desirable stories, but not necessary
Won't-Have	Stories that will not be included in the current iteration.

This method helps teams categorize and focus on critical user stories while allowing flexibility for less vital ones.

I like this approach because: This is great for a first-pass at prioritization: at any point in time, there are some user stories which simply NEED to get done: these could be hygiene features or simply mandated features that your biggest customer has demanded asap prior to renewal. 

3. Weighted Shortest Job First (WSJF)

This prioritization technique used in Agile and Lean software development, particularly within the context of Scaled Agile Framework (SAFe).  

WSJF is calculated using the following formula:

WSJF = (CoD + CoR) / Job Size

CoD (Cost of Delay)	This represents the business value or impact that a particular user story or feature will deliver. It measures how much financial loss or opportunity gain would be associated with delaying the implementation of that item.
CoR (Cost of the job in Progress)	This factor accounts for the ongoing cost incurred while the job is in progress. It considers aspects such as the operational costs or maintenance expenses that the organization bears until the task is completed.
Job Size	This refers to the size or effort required to complete the user story or feature. It can be measured in various ways, such as story points in Agile development.

WSJF scoring focuses on end value, the pain (which is increases over time) of waiting for the product feature as well as the effort needed

I like it because: it recognises that there is cost of NOT doing a feature: inefficiency or lost revenue (or ear-bashing from a customer) whilst the feature isn't in the product.

 

4. Kano Model

Features are categorised based on whether customers positively or negatively value the enhancement

Basic Needs (Must-Have)	The essential features that customers expect as a minimum requirement ie Hygiene Features. Without these features, customer dissatisfaction is almost guaranteed. However, fulfilling these requirements typically does not lead to increased customer satisfaction.
Performance Needs (Linear)	Features that correlate directly with customer satisfaction. As the performance of these features improves, customer satisfaction increases. These features are often explicitly stated by customers.
Excitement Needs (Delighters)	unexpected or surprising features that have the potential to delight customers. When these features are present, they can significantly boost customer satisfaction, but their absence doesn't necessarily lead to dissatisfaction. Customers often do not express these desires because they haven't experienced them before. Differentiating Features
Indifferent Needs (Neutral)	The presence or absence of these features doesn't significantly affect overall satisfaction.
Reverse Needs (Unwanted)	When present, can lead to customer dissatisfaction.

I like it because: sometimes you need to build features that have sizzle, even if your user base has limited utility. As I write this in Autumn 2023, every company has to have an AI strategy, regardless of whether their market has a use for it. 

Conversely, Many new product managers think that adding more functionality inevitably adds to a product. NO!! When the quality of a new feature is less than the rest of the product, it detracts. When an feature is simply odd when considering the product as a portfolio of features, it detracts because it confuses the user.

5. Value vs Effort Matrix

Each feature is scored as to its effort (x-axis) and its value (y-value). My own Feature Prioritization and Roadmapping uses this technique.

High Value + Low Effort are immediate candidates. Low Value + High Effort will never be done.

What's left are all the features that require more head scratching. This technique can help, but it will absolutely NOT provide a prioritised list, but it will definitely uncover some assumptions and biases - see read my article for more commentary.

I like it because: Well, this is the one that when serious prioritisation is required, this is the tool that I pullout of the bag.

Conclusion - what do I really use??

Well kinda a blend of many of the above:

1. MoSCoW flushes out the hygiene features.
2. The time-cost of NOT having a feature is next most important
3. Ongoing investment in the Linear Features (from the Kano Model) with due regard to continuously topping up investment in Differentiating Features.
4. Use Ring Fence Development (on Page 3 of my Feature Prioritisation article) to make sure you have a reasonable balance between bug fixes, hygiene features, linear development and big innovation bets.
5. Once a year, do a product portfolio analysis (using Feature Prioritization and Roadmapping technique) to benchmark all significant future projects against each other. For product enhancements that are requested after the annual review, measure them against a couple of existing projects that have already been benchmarked.

And Why?

RICE, WSJF, Value vs Effort all require heavy-duty future predictions and detailed analysis using difficult-to-find information from other parts of the business. 

They are only really worthwhile for large products decisions whose features / technology dependencies are relatively independent of each other. 

MoSCoW and Kano use simple categorisation to drop feature requests into buckets. Ring Fence Development (on Page 3 of my Feature Prioritisation article) permits the product to move forward on a number of fronts, each effectively having their own backlog.

MoSCoW 

The tough end of product management - sunsetting or cannibalising a product

Sunsetting a product (elegantly) is far harder than creating a product. And cannibalising a existing product with a new one is the hardest of all.

New product development is easy. If it was house-building, you get to choose the brick and where you're going to put it. With sunsetting, it's like putting a wrecking ball through someone's home and expecting them to like it. 

You could say that agile / continuous delivery is the ongoing process of product replacement. True - but the replacement is only modestly different and hopefully better. The cannibalisation that I am referring to is the line-in-the-sand-never-to-return replacement.

Why so hard? An example of the unintended complexities of sunsetting a product

Once upon a time, my management team (inc. me) made a decision to terminate a product: the product had revenue and customers who loved it, but the market's requirements were increasing and the product's market position was being eroded. The investment required to bring the product back into the forefront of the market was significant and ultimately, the returns were better elsewhere in the product portfolio. 

In considering all the ramifications of no longer selling the product, I realised that one of the sales team, let's call her Elspeth, got about 50% of her commission from the sales of this product, as all leads were passed to her. As a result of the (correct) decision to close down the product, she would most probably quit and I thought she was someone that we should keep.

I went to the Head of Sales and pointed this out. He agreed and, as a result, he initiated a territory reassignment, which - and stop me if you've ever been through one of these experiences (*) - took weeks to design / approve / discuss with affected parties etc. 

In the meantime, as the product manager, I oversaw many operational decisions about the product too. I had to try and keep sales going, but approve as few contracts as possible without pissing off Elspeth too much. For example, I had to throw down lots of impediments to each sale: “There's no capacity to deliver that", "Technically, those requirements are challenging", "Ah, that customer will require new functionality that's planned for the next quarter." etc

This, of course, made Elspeth furious - she could see her targets / commission draining away. Complaints were made up and down the company about how I was obstructing every sale. Technically this wasn't true, I approved some deals in order to keep the wheels turning without making it SUPER obvious that sales and delivery was grinding to a halt. Indeed, Elspeth started to believe that I had a personal vendetta against her.

Eventually the territory reassignment plan was all agreed, Elspeth had some new turf carved out for her. She was given some commission for the sunset product sales that she should have won. And finally, we could implement the sunset plan - a plan that had plenty of moving parts in itself: letting existing customers know, properly killing deals in the pipeline, changing the website, redoing sales & budget forecasts, internal comms, etc.  What a lot of stress. And Elspeth finally forgave me!

(*) Territory realignments are painful because: 

• What happens to deals where the customer is just about to sign? 
• What about that tacit knowledge of the customer's business and relationship that the sales team has generated?
• What do you do with commission for deals have been initiated by one sales gal but closed by another? Does credit go to the initiator or the closer or both - and in what ratio? 

This becomes harder when sales revenue is recurring as in SaaS businesses.

Other scenarios: 

• What about pilot or pathfinder deals - deals that prove a concept with the expectation that future business would result? 
• When the SaaS revenue is highly variable or seasonal?

Easy cannibalisation 

Swapping out an old product with a new product is easy if the new product is bigger and better in every way and cheaper than the existing product. If the product is more immature, has less functionality (at go-to-market), has a different pricing structure than the old product - what a surprise - you may encounter market resistance. 

• "You haven't finished the product that you sold me X years ago." 
• "I can't run my business without features X, Y and Z." 
• "What? How much more? Are you mad or am I hard of hearing?"

What about internal resistance? Yes, there can be no shortage of that either. If you change the price / pricing structure, it can destroy existing deals in the pipeline (sales, account management & customer support hate you) if the price is more expensive. If the price is cheaper, then sales, account management and finance hate you, as revenue plunges.

Some recommendations from someone that has gone through hell:

1. Make sure you have the big picture justifications absolutely nailed and bombproof.
1. Expressions like "Trust me, it's hard" and "It's been decided - it's very complex" will undermine (product) management in the mid-term, never mind the long-term.
2. Understand your customer base - and the outliers. Handle the outliers with great care - the customers themselves and the internal teams that support them.
3. Do NOT assume that you will convert every existing customer to the new product.
1. List out the customers that are most likely to flee and make sure that EVERYONE understands that these accounts are at risk and assume that you'll lose some. 100% conversion is simply naïve.
2. Make sure that execs are fully onboard if these customers threaten to flee - and they are briefed when they get calls from furious customers (and colleagues).
3. If it is obvious that the outlier customers might flee, then is the company OK with it? (I mean really???)
4. Make sure that someone (it may not be product management) has done the analysis of which colleagues might leave (that the company actually needs).
1. This is super difficult, as some of the reasoning behind sunsetting a product might be associated with technology and skills sets. 
2. There is an implicit assumption that colleagues will blindly follow an executive decision. The very people that you want to retain for their business knowledge may flee because their product / technology has been jettisoned. 
5. If you think that product managers should communicate (and they should!), then DOUBLE OVER-COMMUNICATE when sunsetting a product.
1. Herein lies the hard part of sunsetting a product - a decision to cull a product may require a rapid execution in order that the process doesn't spiral out of control. However, the very people that you need to consult to make a competent decision may be sufficiently ill-informed to advise you.

Finally, best wishes - bridging the chasm between old and new products, especially if it involves repricing is the toughest job in product management!

Product Management for Corporate Glue AND Lubricating Oil

Product Managers have a fascinating, all-encompassing role. They can be called many things, CEO of the product, Janitor, Super User. See Product Manager is a janitor basically.

All other business functions are well understood: 

• Engineering develops the product
• QA assures that the product 
• Sales converts a product into justifiable business value for each customer
• Marketing communicates the product proposition to a market of similar users / buyers

etc

But what do Product Managers do? 

• Product managers are frequently the glue that keeps the rest of the business functions inside a technology organisation stuck together. They fill in the cracks in between all these business functions.
• And they are the corporate 'oil' that lubricates other business functions within the company, making each function more efficient and in better harmony with each other.

Example

The next version of the product is coming. It's in Engineering. Product Management has defined the requirements of the product and during the build cycle, it assists with dilemmas and issue resolution.

QA is shaping up to receive the product, but this new version is more sophisticated than the previous version. The QA team need to understand the common use cases / user flows in order to write system / regression tests. They rely on Product Management for guidance.

Marketing is familiar with existing positioning, but this latest release opens up new markets and positioning. They rely on Product Management for guidance: what are the USPs? what are the best use cases? how should it be positioned and to whom? 

Sales may not be able to help for lots of reasons - they want to sell the existing products, not ones that aren't on the price list yet. The rest of the company is dependent on the Sales team selling the existing product in suitable volumes in order to pay the salary bill each month - you really want them sticking to the knitting and selling what's in the warehouse now, not yet-to-be-proven products still on the production line.

Additionally, they have had limited exposure to it: feature and functions aren't well understood yet, positioning isn't developed, use cases and case studies are embryonic at best

Account Management and Support want to know what's different about the new product and how can it be positioned to existing customers and how can they benefit most from it. Is it as good as the existing product? Can existing customers try it before they buy it etc? What the known limitations?

So, often it is the product manager / marketer that goes prospecting for beta customers and manages the beta programme(s) to their successful (hopefully!) conclusions. See the The challenge of beta programmes and Product Launch vs Release vs General Availability vs Deployment.

As a result, it is Product Management who is at the heart of technology product company, acting as its glue and the oil - and that's not contradictory!

See also How everyone else views the first-in-post product manager

ChatGPT for product management

With the release of OpenAI’s ChatGPT at the very end of November last year, there has been an explosion of enthusiasm. Here’s their trajectory to a million users!

(Thanks to Azeem Azhar of Exponential View)

Initially, the response was ‘Look at this cool poem that ChatGPT wrote.’ Thankfully more considered use cases are now developing.

So here are my thoughts on how ChatGPT can help Product Managers:

Broad Use Cases	Use Cases for Product Management
Summarisation of a long body of text	Summarising large amount of texts for requirements analysis chatGPT is surprisingly competent at summarising text eg for condensing a whole list of free-form product requests from customers into a couple of pithy themes.
And the inverse, extrapolation of short body of text.	Writing product descriptions for product marketing. a. Reinterpreting features to benefits b. Rewriting product marketing copy for particular audiences
Variation of an existing body of text	Wearing your product marketing hat, you have written some descriptive words, but they need some help or the body of text needs to be shorter to fit into a text box on the website or on your PowerPoint.
Initial research into a topic or industry	As Product Managers, we spend a lot of time trying to make sense of a market / customer / technology / product / service. I can see myself using chatGPT as a great start to understanding the four walls of a market. Market research: what do I need to know about XYZ? What’s new and important in the XYZ sector? Who has the competitive advantage and why in XYZ sector? It’s great a high-level summaries, but not good enough for the details that matter.

As always the devil is in the details, but at least it gives the Product Management some boundaries and some structure to start with. And you would never submit the output from ChatGPT as your completed, best thoughts, BUT it does provide a start and save on that first half hour / blank canvas problem / writer's block when you’re wondering where to start from.

ChatGPT for managers

One great advantage is that it can create consistency when you have review or compare work from multiple teams. By getting your teams to start with ChatGPT's output, then at least all the teams have started from the same point with their use case (not using a template).

What it won't do effectively?

Some have claimed that it could be used to write product requirements. Nope – well, not to a meaningful level and certainly not good enough to give to a developer.

Cute Use Cases

• There’s one elegant use case of writing a Value Model Canvas.
• I Interviewed ChatGPT for a PM role, and it almost got the job

Side Notes on OpenAI

• Who are their investors - it's always useful to know where the money flows. 
• Y Combinator
• Peter Thiel (founder of Paypal)
• Reid Hoffman Foundation (founder of LinkedIn)
• Khosla Ventures 
• Elon Musk did invest, but has now sold off his stake
• Microsoft Ventures ($1bn investment in 2019 + MS has built a supercomputer in Azure to support OpenAI ML research)

OpenAI have more complex corporate structure than most: there is for-profit corporation OpenAI LP and its parent company, the non-profit OpenAI Inc. AND in 2019, OpenAI transitioned from non-profit to "capped" for-profit, with profit cap set to 100X on any investment. (Source: Wikipedia)

Product Management in big companies vs small companies

If you haven't already, then I urge you to look at the product management resources at Lenny's Newsletter. His top articles are really REALLY good. Sign up for the newsletter too - you won't be in bad company, there are over 300k subscribers.

Lenny was my Head of Engineering at Webmetrics (San Diego, California, about 25 people), when I was his (only) Product Manager - see case study. He left to co-found a start-up which was acquired by Airbnb where he was one of its first product managers becoming Head of Growth. He has since left Airbnb and is now an angel investor and writer. Super smart and a super nice chap. 

I loved his article on Startup PM vs. big company PM and agree with everything he says. 

There are a couple of points that I'd like to augment: 

Startup PM		Big Company PM
Optimise for speed, learning and reuse	⭢	Optimise for quality, impact and completeness
Define the product culture and processes	⭢	Optimise the product culture and processes
Validate (or not!) the excitement of foamy-mouthed CEOs / innovators yourself	⭢	Get others to fill-out a business requirement specification and to follow the process
Justify the product roadmap to others	⭢	Successfully navigate the business process that slots engineering time to work effort
Optimise processes in other business functions	⭢	Stick to the knitting in your own department (or escalate the problem up the org structure!)
Beat the drum for the whole organisation	⭢	Follow the beat determined by the corporate strategy
Dream of some stability in the product creative process	⭢	Crave some innovative time to fix stuff without constant justification
Spend your day saying, "No, sorry because...."	⭢	Spend your day reviewing other people's proposed product enhancements

Requirements are like meteorites

"Perseid Meteor Shower 2016" by Jaykhuang is licensed under CC BY 2.0

There are lots of them, many of them (the majority??) are 'out there', floating around in space: oddly-shaped, unloved, cold and alone. The ones that we can see are pointing towards us. 

Once in a while, a requirement will ignite into life, perhaps it gently bumps into other similar requirements and they coalesce together and starts to gravitate towards Product Management & Engineering  - these are long term trends

OR it gets knocked out of its static orbit and accelerates at speed towards the organisation (eg as a result of some action by a competitor or a positive reaction from a key customer after years of talking about it) 

OR perhaps it become super-charged (eg demanded by influential customer or CEO after a conversation with a key investor / board member / conference / brain wave).

The outcome is that it comes spiralling in towards Product Management who scramble their X-wing fighter jets and head out towards the requirement to survey it. Is it cloud of confused strafing dust or some small pebbles without any real momentum? 

OR a substantial requirement but it doesn't match our strategic intentions / won't impact our market(s) / unsuitable for our technologies - broadly an opportunity that's not suitable for us. These sail on passed us and can be classed as a 'near miss'. 

If, as product managers, if we have nothing better do, might toy with these near misses, entertain them, enticing a beta customer or two by asking for their requirements, provide pricing and implementation plans, perhaps even get as far as a contract. And then side-step the requirement and allow it to slam into a competitor and make a mess of their sales plans, product roadmap, operational plan and account management and customer support. 

I have done this once - I wish I could say intentionally - and months and month later, at a conference, I was chatting to a competitor and learnt how said customer had wasted months and months of pre-sale / sales / executive time dealing with said customer, before it all went puff in a cloud of smoke. Gleefully, I shared with my competitor that we spotted it as bad business when it was on the edge of solar system and made sure that it did no damage as it sailed on through. 

Some requirements become direct hits - they will need nudging and steering (targeted comms eg pertinent case studies) and / the application of powerful magnetic forces (aka tenacious sales / implementation / account teams). Some will need feeding with a string of breadcrumbs that lead in your direction (aka MarComms, social media activity, continuous marketing activity, enhancing brand presence).

Some are bolts out of the blue: a perfect cohesion of some good technology plus a powerful gravitational market pull. Clearly, these are the ones to pay attention to. Some immediate questions - just to guy check that it is worth spending tooo much time on the idea

• What are the resources needed to capitalise on it? 
• Does it fit into our portfolio - should it?
• How big is the market for the solution? And can we validate this assessment this quickly?

See also: 

• Fitting Products to Markets (and vice versa), in particular the section on The Perfect Cancer Drug - an example of Sustainable Revenue
• Feature Prioritization & Product Road Mapping

Kim Cameron and the Seven Laws of Identity

Kim Cameron, who died at the end of November, was the author of the seminal Seven Laws of Identity in 2004, which remains a super test of the good use of personal data and identity. A good man & a man for good - RIP.

Working in identity in the early 2000s, I remember early versions of the Laws being circulated by Kim when I was working at Midentity.

The Law of Identity in summary

	Title	Description
1	User Control and Consent	Technical identity systems must only reveal information identifying a user with the user’s consent.
2	Minimal Disclosure for a Constrained Use	The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.
3	Justifiable Parties	Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in agiven identity relationship.
4	Directed Identity	A universal identity system must support both “omni-directional”identifiers for use by public entities and “unidirectional” identifiers foruse by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
5	Pluralism of Operators and Technologies	A universal identity system must channel and enable the inter-workingof multiple identity technologies run by multiple identity providers.
6	Human Integration	The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks
7	Consistent Experience Across Contexts	The unifying identity metasystem must guarantee its users a simple,consistent experience while enabling separation of contexts through multiple operators and technologies.

Product Stack - all the tools for today's Product Manager

Product Stack - a comprehensive visualization of the tools and solutions that serve the modern product leader

Also see their ProductCraft's free tools directory

Credit: ProductCraft

 

A Zoo of Management Acronyms

image from DeanOnDelivery.com

You may well have heard of HiPPO, the Highest Paid Person’s Opinion. If everybody in the room has an opinion, it’s the HiPPOs opinion that will win.

Just because it makes us chuckle, it isn't totally invalid. As Jim Barksdale (Netscape CEO, FedEx COO, AT&T CEO) said, "If we have data, let's look at data. If all we have opinions, let's go with mine." And certainly, I would happily surrender my opinion for his his, if we ever went head to head!

Product Focus list other animals in the management menagerie. UPDATE: see their infographic.

RHINO	Really Here In Name Only
ZEBRA	Zero Evidence But Really Arrogant
WOLF	Working On the Latest Fire
SEAGULL	Senior Executive that Always Glides in, Unloads, and Leaves Loudly
VIPER	Vindictive Individual’s Plans Endangering Results
MuMMY	Muddying the waters and Micro Managing You
DODO	Dangerously Out-dated Deciders Opinion
SCAREDY CAT	Says Clear Argument, Roadmap, Execution, and Direction, Yet Changes All the Time
MOUSE	Manager’s Opinion Usually Swayed Easily
OWL	Old Wise Leader
PARROT	Pretty Annoying and Ridiculously Repeating Others
DONKEY	Data Only, No Knowledge, Expertise or whY

Got any suggestions yourself?
We’re currently working on some content that will take this a step further with advice on how to handle each persona. If you can come up with any others – please let us know. If we include yours in our content, then we’d be happy to say thanks with both an acknowledgement and a £100 Amazon voucher.

You might also be interested in this blog post: Product Manager is a janitor basically

The huge challenge of Consumption Pricing

Software Pricing Partners pen some excellent thoughts on the merits of consumption pricing as a charging model: It’s Wise to Question the Big Assumption about Consumption Pricing

The key fact is here: 

Perhaps the most important challenge when considering a consumption pricing model is to align the use metric to the value the customer derives from your solution, which can evolve over time.

This is really, REALLY hard to do: there are inevitable edge cases which destroy the cost of the service or value proposition. For example, number of users vs number of active users vs number of concurrent users when users churn frequently. What happens in cyclical businesses or when there are pulses of demand or inactivity and your pricing is based on transactions per month?

Yes, you can squeeze in acceptable use policies that prevent extreme abuse, but customers get (rightly) irritated at the lack of transparency. 

Alternative billing models (eg flat rate pricing / all you can eat) makes it easier to accommodate some of these challenges, but all models have their strengths and limitations. And that's the key conclusion to draw when building pricing models: it isn't easy and ignore fashion!

Alternative business models: open-source, crowd funding and tokenisation

At the Cambridge Product Management Network meet-up, Liam Crilly presented the fundamental business routes for open-source project. I talked about the various flavours of crowd-funding. 

From my experiences at Fetch.ai, I proposed that open source and crowd funding are prerequisite to tokenised business models. 

I left a question with the audience: If Tim Berners-Lee came to you with the idea of a web server + client browser, would you advise him to open-source or tokenise it?

What do you think?

The slide are available on slideshare. 

Product Management Tube Map

Product Focus have just published their Product Management Tube Map - SUPERB!

As well as being a lovely graphical interpretation of the role of Product Management, it shows the interconnected nature of product management and product marketing with many other business functions.

But Mind the Gap. In many companies, the focus is on Agile and Product Owners, and the strategic & leadership role of product management is missing

How true!

Possible extension to the infographic - 'Ticket to Ride'

The diagram made me think about the skills required to navigate the Tube Map - one's Ticket to Ride, as it were:

• Business Savvy
• Empathy
• Communication skills: listening and clarity in written and vocal transmission
• 'Spidey' sense of what's doing to happen next
• Leadership (vision and direction) and Trust

Signs that your Product Pricing Strategy isn’t Working

My thoughts on Software Pricing's blog about the Signs your Pricing Strategy isn't working.

1. A customer base littered with bespoke deals.

The main problem usually encountered is that there isn't (much of) a discounting policy or it isn't adhered to. When I worked at NeuStar, there was a solid discounting policy AND a robust methodology to go beyond it.

"Special deals" had to be approved not by sales management, but by the product board. This mechanism really did account for the revenue / cost / profitability for the whole customer lifecycle.

2. Purchase options that include unlimited, or “all-you-can-eat” use.

Hmm, unlimited deals should be used when the value of the propositions is too complex for the customer and the vendor to justify, but everyone knows there's significant value. Within reason, as long as costs / burden don't torpedo profit margins, it is entirely valid.

Obviously, it is easier to make this decision when the variable cost of more consumption is tiny.

Fair use policies (whether formal or informal) need to be implemented so that costly abuse of unlimited can be contained. For example, 'burst usage' when greater utilisation is permitted but within reason (eg to a limit or within a period).

3. Prices that don’t account for customers’ varied budget cycles.

Simple statement, but the ripple back of this issue can be massive.

Let's say your customers get paid on a project-basis ie on completion of milestones. As a customer, you'd like to pay your suppliers when you get paid. As a vendor, if income can be guaranteed, this may be acceptable.

If however, the revenue is exposed to risk, this may not be acceptable to either party. For example, the construction industry is prone to delays or changes. As a concrete vendor, payment on project completion is unlikely to be acceptable.

In the software sector, does this change how your product is priced (yes!) or delivered (likely) or built (possibly)?

 

4. Enacting pricing changes without modeling the impact on legacy and net new revenues.

Oh, SO important!

A company releases a new product version that is supposed to cannibalise the existing product. They anticipate that all existing customers will diligently glide over to the new product without churn. 

Oh, how wrong! Any change in product or pricing can lead to re-evaluation of the proposition and the possibility of churn. Please see my work for CDK Global for exactly this problem/

5. Complex or confusing pricing

Value-based pricing is great in theory, but if your product has multiple and diverse use cases, then the complexity of pricing appropriately becomes far too difficult to support. As a result of the practical decision to simplify pricing models, your target market may be sliced to a smaller size – never a palatable proposition, but sometimes mandatory to simplify all sorts of problems, not just in sales, but in product development and delivery and branding.

Product Metrics Spikes

A friend pointed me to How to crack product metric questions in PM interviews. In essence, it discusses how does a service provider respond to a change in a metric or KPI (Key Performance Indicator).

A definition from the article:

Metric interview questions test if candidates can perform data analysis and select key metrics that matter most to the success of a product. Employers like Facebook and Google use these questions to evaluate critical thinking and communication skills.

There are two types of metric questions - one builds on the other

Metric definition questions	Metric change questions
What are the metrics that provide clarity on the health of a product or feature? What metrics matter??	Do you know what to do when a key product metric (e.g. traffic, revenue, engagement, etc.) is going up or down for no apparent reason.

Solving the Metric definition question

The article recommends the use the GAME method

Goals	Make sure you understand how the functionality helps the commercial goals of the company. 80/20 rule - make sure you're measuring the 80% - the stuff that matters!
Actions	What are key activities that indicate the functionality is achieving those goals? This requires good understanding of the product functionality. Make sure that DevOps doesn't define and implement these unsupervised!!
Metrics	Where in the value chain is a good place to position a measurement? Yes or No evaluation is a starting point, but is there another metric that is a precursor to the switch toggling from one condition to another? In web performance management ie website availability and uptime, then "What goes slow, goes down." (see the Webmetrics case study)
Evaluation	What is normal, good or bad about a metric reading? And are the trade-offs and limitations in having this figure? For example, seeing a drop in shopping basket conversions over a 24 hour period might be useless without understanding that there was 60 minute outage from your payment provider.

Solving the Metric Change question

The article provides its own methodology.

Define the metric change	Make sure you fully understand the metric that is being presented to you: What is it and what is it not? You may have to get into the weeds about how the metric is measured. See Actions above For example is 'Page Views' the total number of views or page views by unique users? What happens if the same user logs in and views the page on two devices or two different sessions, how is that logged?
Explore possible root-causes of the change	Use the MECE framework Mutually Exclusive and Collectively Exhaustive = Identify cause(s) that is independent of all others OR understand what the cause is definitely NOT (*). For a metric incident, the root-cause of the problem has to be internal OR external, as there is no other option. If you think there is an internal AND an external cause, then you need to do more research. Did one external condition cascade to an internal condition? Unfortunately, these can be super hard to run down!
Conclude	Make sure there aren't any horrible assumptions that you haven't validated / eliminated.

   
* For info on MECE:

Escalation and Communication

The article hardly touches on the critical, critical point of issue escalation and communication.

After you have done your initial assessment, you need to answer the question: Do I ring the alarm bell and to whom?

Judgement call: Let's assume that (a) the metric isn't a false positive and you've validated to some significant extent (b) the metric matters. So, how high do you escalate the issue?

Factors to consider:

• How many other business functions are impacted by the incident?
• Is that metric important to them?
• Can they do something about it, either to resolve it (eg some root-cause analysis) or to reconfigure their business function to accommodate the impact of the incident?

I recommend using this yard stick:

Level of concern	Action
Not a concern or quickly solved and implemented	If you are sure that impact is minimal and contained, then I recommend concentrating on solving the issue. You can report that the problem was resolved with minimal impact. Warning: if you get stuck in the resolution, then you quickly have to over-escalate the issue eg to 'Very concerning'
Somewhat concerning, but impact is contained	Keep researching until either you hit a brick wall or an unreasonable amount of time has elapsed
Very concerning	More business functions are required to investigate and you need to escalate it to a suitably high level to get resources devoted to it. When communicating, be clear to separate known symptoms vs known conclusions to date vs guestimates as to possible causes, articulate mitigating factors and (partial) resolutions that have been applied to date.
Ridiculously high	This is a hard one to call. You most probably know that something basic has gone wrong and that others have spotted it and are working on a solution (and may have even resolved it). However, that is a dangerous assumption. It's best to escalate it - even if it is likely to be a false positive.

The importance of communicating - and re-communicating

As soon as you communicate outside of your team, make sure that someone is knowingly and consistently appointed as Incident Manager (ie it could be you!). Note that if the problem rattles on, then you may need to appoint a Communications Manager in front of the Incident Manager to protect the Incident Manager from simply responding to communication enquiries rather than actually working on the resolution.

It's best also to alert other business functions how you will update them on progress and frequency of updates (even if there is no progress).

Use of incident support tools

There is a great danger in over-engineering the use of incident support tools. Over-engineering = it is too clumsy or laborious at the point of the crisis. If others aren't familiar with the tools, then they will still ask for email / telephone / instant messenger updates anyway!

Next step: Deep Dive into Root-Cause Analysis

Once you have done your initial assessment and then communicated your initial findings to relevant business function, it's time to dive deep to separate symptoms from root-cause. You may need access to multiple test and near-production systems(*) to validate theories.So do make sure these are functional before the crisis hits.

Do ask around your team (DevOps, Release Management, Testing, Engineering) for their input into symptoms and route cause. In many circumstances, something similar has been seen before.

Cycle back with colleagues and partners based on status and resolution - instant messenger is fab here!

(*) Near-production = an environment that mostly closely replicates your live or production environment

Multiple resolutions

There may be several resolutions available: there's a matrix of time horizon vs cost-benefit.

Multiple resolutions might be appropriate - and that's absolutely appropriate to pursue several simultaneously. eg roll-back recent enhancement; test proposed partial fix; kick back to engineering for a rework with new testing scenarios etc.

Product Managers: Now, Next, Future

Steve Johnson, one of the respected voices in Product Management, cleans up some of the confusion about product roles and titles in Product Management. He admits that he (like me) is fan of  the “product management triad” - a product or portfolio team responsible for strategic planning, release planning, and launch planning. Here's the link to the particular post and full description of these roles. 

Title	Scope	Comment
Product Strategy Manager	Future	Evaluates and prioritizes future products and the portfolio
Product Owner1	Next	Focuses on what’s next in terms of features and product options
Product Marketing Manager2	Now	Focuses on products that are currently available

¹ Steve prefers Product Planning Manager - yuk!

² Steve prefers Product Growth Manager - yuk!

I do like the time box approach to the focus of each of these roles. Of course, this is simplified. It's not as if the Product Strategy Manager slurps espressos all day and pays no attention to the last quarter's sales figures or the Product Marketing Manager isn't constantly assessing the competition's capabilities and figuring out how to 'out-product' their offerings.

I would also recommend studying this Product Taxonomy from Product Focus (providers of product management training and resources - and one of the sponsors of the Cambridge Product Management Network).

Here's my take on 'Who owns what' which dovetails with Product Strategy vs Product Owner vs Product Marketing

Portfolio - owned by Product Strategy Manager

Responsible for managing the portfolio. He / She isn't the only decision maker. This is best managed by Product Investment Committee - this is a beast in its own right - but this has representation from Sales, Marketing, Product, Engineering, Research plus some financial modelling expertise.

The Strategy Manager often takes on the long-term management of the core platform, as moving the platform forward requires care and evaluation, because key decisions may negatively impact capability of the products that are built on top of the core platform. ie mods to the core platform are expensive and time-consuming to get right.

Propositions - owned by Product Marketing

This is the realm of product marketing. Product Strategy may be involved if there is cross-subsidisation of prices between products (or product lines) and platforms.

This area gets super complicated when propositions vary between countries / region of the world. Different countries may provide functionality for free (or charge for free functionality!) for a whole variety of valid reasons (local commercial agreements, tax or legal reasons, history & politics, how core product development costs are charged to territories). This is matter is worthy of another blog post or even a book!

Products - owned by Product Owners

When considered in a portfolio, this is the domain of product owners or, if the product is significant enough, a manager in their own right.

How everyone else views the first-in-post product manager

CEO mutters that maybe it is time to hire a product manager.

Everyone else wonders, "Err, and how will they help?" And they get that uneasy feeling that the company is going to be less fun and more restrictive and more "NO!" Perhaps the first publication of the Employee Handbook had the same reaction - mildly menacing, but necessary for some (other) slightly dysfunctional part of the business, but not for me.

Below I augment the great story that Product Focus (a well-regarded provider of product management training) tell in their Product Leadership Workshops and, to some extent, is outlined in their publication, "What is the point of Product Management?"

Here's the history of a B2B software company and the welcome emergence of product management.

The small company was founded on technical innovation and good customer service to its early customers. Initial Product Management is executed by the CEO. The company continues to thrive, and the CEO's time gets further and further sub-divided, but the technology and the product remain his/her passion.

But a new Sales Director joins the company and complains, "We’re a technical-led company. We need to become customer-driven." And that sounded fine except every new contract required custom work. Contracts were signed with a dozen clients from a dozen market segments. Soon the costs to support all these different products started to escalate. The latest customer’s voice always dominated the product plans. The CEO concludes that “customer-driven” meant “being driven by the latest customer”, and this created short-termism to the frustration of Engineering with the creation of massive technical debt and the sense of favouritism towards particular Sales team(s) creating lots of subversive backdoors to decision-makers. The price list becomes a joke, as the Sales team somehow manages to get colossal discounts on big deals using the mantra of 'a strategic customer deal,' without regard to profit margin. 

When a board member declares, “We’ve become a sales-led company. We really need to start being market-driven,” a brand specialist is head-hunted away from a big consumer product company to be your VP of Marketing. As part of a re-branding initiative, she designs a new corporate logo with a new colour scheme for the web site, new collateral, and an updated trade show booth and a big expense budget for conferences. Hundreds of thousands of dollars are spent without any change in revenue.

Soon the CFO whispers to the CEO, “Don’t you think it’s time we started controlling costs?” So, the company becomes cost-driven and started cutting out all the luxuries like travel, technical support, bonuses, and employee appreciation. Everything had to be justified with a business case and the CFO was tough on any assumptions – the only things that got past him were small evolutions of existing products. Account management was lauded for winning incremental business, usually with small but exotic customisations which started to build technical debt and make upgrades to new product releases more and more painful. And, innovation stalls, engineering resignations escalates!

At this point, when Finance has gone too far, margins have suffered, and the future product pipeline looks thin and also-ran. The CEO steps back in and is sorely tempted to take the company back to its technology roots but he/she knows that this needs to be tempered with supporting existing customers and protecting existing revenue streams. So, a new, hybrid approach is required – so the company recruits a product manager.

The CTO and the Head of Engineering welcome the idea. Finally, the Product Manager is the go-to person to make sure his/her team build the right stuff and have a solid, defensible product strategy. This prevents his team/technology from being yanked around all the time OR working on the latest, crazy C-suite initiatives OR brainless product customisations for the big customers, that don't make sense and will become a mill stone around the neck of Customer Support in the future.

But the Head of Sales is also keen. Her team can’t answer the tough questions customers are asking. Finally, someone with lots of product expertise can answer technical questions without murdering customers currently in pre-sales with infinite complexities and CLOSE SALES! The perfect PM should answer customer RFPs (Request for Proposals); AND come out on sales trips whenever they’re needed; AND be the demo jockey; AND talk authoritatively about future product releases and when they will occur. They should also be able to write some technical whitepapers and do some decent competitive analysis.

Marketing, who if you’ll remember lost a lot of credibility with their splurge on branding, are also having problems with their collateral. Their vague product brochures and website content don’t seem to hold customers' interest and come in for a lot of criticism from prospects and internally. The Product Manager can explain the product once and for all, providing decent product messaging and propositions for the collateral. A product roadmap with some realistic dates would allow her to plan marketing spend, rather than a knee-jerk reaction to product releases or to cancel events sponsorship at the last minute due to another slippage in the product release date.

Finance is relieved to hear about Product Management arriving. Finally, there’ll be someone to hold accountable for whether each product is making any money. The CFO immediately starts working on a new, complex, business case spreadsheet that the Product Manager will be tasked with completing and comes up with detailed KPIs that the new product managers will measure for him!

By this stage, Account Management & Customer Support have almost lost the will to live. Every day, they writhe in agony trying to solve exotic customer problems which Testing and Engineering struggle to recreate, never mind solve. They see the new Product Management team as the last hope to solve the Sales madness of selling solutions that are further away from the core product offering and hanging Customer Support out to dry AGAIN. Otherwise, they are definitely throwing in the towel and quitting.

Conclusion

Everyone has their view of what the perfect product manager should be doing – it’s helping them do their job! In truth, Product Management should be greasing the wheels of all these business functions because they put the product's holistic success at the centre of what they do..

About Arthur
A Product Manager who enjoys taking new technologies and concepts to market. Fascinated by software, internet and mobile sectors. Start-up and scale-up specialist. Based in Cambridge, UK. For more information, see www.stream121.com.

The challenge of beta programmes

In a previous post, I looked at the Product Management & Product Marketing model that Redgate Software (a local Cambridge-based company) uses. In it, I identified a component, that didn't appear to be addressed: beta programmes. 

 

A quick diversion into pronunciation

• In the UK, it is pronounced 'Bee-ta'.
• In the US, it is pronounced 'Bay-ta'

It's a pronunciation that I found far, far difficult to surmount when I moved to the US and when I moved back. 'Tom-mart-to' and 'Tom-may-to' was easy!

What is the purpose of a beta programme?

The build team (Engineering, Testing, Product Management, Implementation, Technical Support) want the beta programme to technically validate the latest functionality - that it works outside the lab, in real customers hands and that bugs are flushed out and those bugs are validated in subsequent releases. The end goal of a solid product should not be compromised by time constraints.

• Marketing and Product Marketing want a case study and a quote for the press release - as soon as possible please.
• Sales, Sales Engineering, the CFO wants a big name brand to do reference case study that ignites the sales pipeline - ASAP as well.

Hmm, plenty of different objectives!

Why should a customer participate in a beta programme?

I'm sure that we have all participated in these CBT (Customer-Based Testing) programmes at some point: buggy software whereby the customer does the testing - seemingly to the shocked surprise of the vendor. This can be immensely damaging to the beta programme, the provider’s brand, the relationship between participant and the provider.

And, for the customer, it's a darned good reason not to participate in a beta programme: too much effort for no advantage (or indeed negative advantage).

For this reason, providers need to ensure that, during the beta, they have the Engineering bandwidth to rapidly fix issues that are identified. This, of course, is difficult to estimate exactly how much resource is required, but essential that this remains top priority. Unfortunately, Engineering’s core capability of building beautiful, well thought-out functionality does not match the issue + investigation + quick response cycle of beta programmes – expertise that is embodied in Support or Professional Services.

Valid reasons for customers to participate in a beta programme are:

• Access to latest version - see later for my experience with CDK Global
• High-profile within the vendor's organisation: ie access to Technical resources or insight into the vendor's strategic intentions.
• Cost-reduction in fees, perhaps for a limited period

Which business functions should participate in Beta Programmes?

There are many good and bad reasons why different parts of the organisation should participate in beta programmes.



Customers
Err, yeah, of course, but some customers have a different propensity towards beta programs.

Customer whales (ie big ticket customers) that that are currently in pre-sales should definitely not be part of a beta. It may destroy the sale altogether: experience with buggy software may leave a nasty impression in the mouth - even if it is exactly the functionality that they are begging for.

Getting a quote out of a whale's marketing department may take months, if at all.

Beta software is usually provided at a discount - possibly a significant discount - a discount which may never be recovered on full release and therefore full price - and too expensive a margin to surrender.


Existing customers are great for betas - they understand what the previous product does, users and the business buyer have a positive relationship with the beta provider. Technically and financially, the provider has been validated and approved. This certainly makes it easy to draw up a shortlist.

However, there may be enough 'baggage' in the account that existing customers may derail the beta at the outset. They may demand so-called 'fixes' (missing pieces of functionality that they perceive in the existing product) or their environment / use may not match the requirements of the beta functionality. They will want compensation for their participation - and this compensation may be more valuable for them then the business benefits of the beta software.

Some of the best beta programmes I have participated in have been with new business divisions of existing customers. Commercially an existing contract is easy to extend. The vendor sees new business and the customer has the assurance of existing proof elsewhere in their organisation.


New Customers
New, NEW customers can also be really good. They genuinely behave like new customers.
They generally have more operational flexibility - they haven't honed their own processes to your product yet - and recognise that they need to create new processes.

Existing customers may say, "Yes, we'll be on your beta - as long as the product is "better" and nothing changes." Well, if the beta product aims to cannibalise the existing product, then the beta product will be "different" - better in many respects, but different in others. These differences may be negative enough to existing customers that they outweigh the new advantages.

The issue may be become more apparent if the existing customer is now off-centre from the target market with the new product. Existing customers may feel that they are being shoved to one side by the relentless progress of the vendor - and this may give the existing customer on the beta programme a sour taste in the mouth.

Another advantage of new customers is that the beta programme doesn't have to tiptoe around Account Management or Sales and get their buy-in.


Testing
Testing needs to valid the software on its way out and also to validate any issue as reported. For this reason, it is often essential that Testing has access to an environment that has beta code on it - let's call it pre-production - they are interested in isolating the real-world issues in a lab environment. Messing around with the production server is not to be recommended as it may create serious degradation to the service.


Engineering
Well, yes, they created the software and they are responsible for delivering it and fixing it. They are critically interested in technical validation in real-world environmental.


Account Management
If an existing customer is involved, the participation of Account Management (or Sales or Professional Services or whatever function manages existing relationships) is undoubtedly required, particularly at the start and end of the beta programme.

This function is compensated with incremental revenue - quite rightly, they don't want to jeopardise their account with the unknown. So, account management need reassurance that their customers' participation in the beta will help their account.

If the beta programme runs in parallel with existing product, then Account Management and Customer Support continue to support the existing in-life product. If the beta programme cannibalises the existing product, then the beta programme manages and supports the customer.


Customer Support
This function is generally wary of beta programmes, as it is often increases the amount of first-line call handling that they are required to do.


Implementation / Professional Services Team
The participation of ProServe is dependent on the amount of customisation required for the beta customers. Development would like 'vanilla' customers with the least customisation. However, this is dependent on the interest of the existing customer base in the beta programme and, with gritted teeth, the beta programme may be obliged to accept a highly customised account into the beta.

The great hope of vendors is that the new version fixes lots of issues in existing accounts - helping Account Management / Sales (unlocking new revenue), Professional Services (less implementation grief) and Customer Support (fewer issues and better relationship). And yes, it should leapfrog the competition and trample all others in the marketplace.


Special Cases - Saturated Markets
Newly all of my product experience has been in small scale-ups. However, I did have one fascinating experience working for CDK Global (see case study). As the Release Director, I was also involved with the Beta Programme - admittedly at arm's length.

CDK Global's product was the first major release in 12 years. It is worth mentioning because CDK Global dominated their market with 60%+ Total Ownership. Their customers (car dealers) operated in a highly competitive market and any new advantage could significantly tip the market. So, getting on CDK Global's beta programme could be a game changer in the short- and mid-term. When a slot on the beta programme was offered to a shortlist of existing customers, each place was eagerly snapped up.

Conclusion

Beta Programmes are extremely important to software creation teams, but managing these diverse expectations can be equally difficult - particularly when the product launch (with all those expectations!) is dependent on it.

Product Management and Product Marketing - a perfect union in B2B

Redgate Software explain how they define Product Managers and Product Marketing for B2B software - and how, together, they make a perfect union to bring products to market and how those products are consumed.

Their model (above) is based on the SiriusDecisions Product Marketing and Management Model which is reproduced below for ease of consumption as it is hidden behind a (free) registration wall (too much of an impediment for its value, IMHO).

Redgate's description is an improvement (much clearer and tighter in scope) where as SiriusDecisions diagram is more encompassing by slotting product in between marketing and sales.

Redgate's version shows the division of labour and where they work together.

Beta Programme Management

The only thing I see missing from Redgate's model is a beta programme management - which is referenced in SeriusDecisions model.

In my experience, the beta programme can be managed by either party, but best led by Product Marketing initially, who are closer to the customer. However, the lead may change in a small beta programmes, under three circumstances that I can think of:

• The beta programme is very technical in terms of functionality and requires of Engineering's expertise to implement or generate significant value OR
• The latest release uses novel technology which is 'sensitive' (shall we say!) or both the rest of the organisation and the customer don't understand OR
• The beta has significantly more technical issues than anticipated and effectively Engineering has to jump in and effectively resolve and effectively they run the show.