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.