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.