Mark Taylor, Collaborator, Lean-Agile Business Practice
There are two spots where products in development most often lose their way. In the first mile because the
initial wave of requirements are 1) vague, 2) context-less, and 3) not from a representative market sample.
The next where-am-I point, the last mile, is where the DONE target keeps moving, often because of unrelated events; for example, a competitor’s product announcement, an individual customer’s last minute demand, and
a product manager’s launch remorse.
The First Mile
Vague requirements frequently happen for 2 reasons
1. A business unit can’t keep up with the requirements pull from a high velocity Lean-Agile development silo and, dare I say, make things up.
2. Requirements come to the development team as a feature list rather than a context sensitive story.
Silos of any kind are a precursor to a train derailment if not a full wreck. This holds true for a Lean-Agile software team silo. The best starting point for a Lean-Agile initiative is with a product team that includes all the functions needed to take a new offering or enhancement from the defined and validated market pull through to launch and life cycle management.
That being said, the vast majority of Agile initiatives start with the software team; and those well managed see, for a time, significant improvements. Then the Agile software silo runs into the rest of the non-agile organization and stalls. Hardware teams can’t synch up, marketing can’t deliver context- validated requirements fast enough and release operations can’t handle the volume of ready-to-go offerings delivered to their doorstep.
We’ll address the hardware and release operations chasms in a separate article.
In the current age of “I know what I want and I want it now” the defined and validated requirements gathering process needs to be done in a continuous, synchronous flow. Continuous because the elements that affect the market condition change weekly, yes weekly. Synchronous because, at that rate of change, the other product team members need to know about changes ASAP to avoid going too far down a path that will need to be backed out of.
Why is context important? The “Here’s the features, build it and they will come” mantra actually never worked. Numerous studies have shown that as much as 60% of product features are not used. Rather than ask a representative sample customer “What do you want?” ask, “Tell me about your day, week, month, quarter.” That way you find out not only what they want, but also how it will be used in different contexts.
Who do you interview: the user, chooser and approver? Why? Context. The user is at the desktop, the chooser, usually a manager, is concerned with team and tool collaboration, and the approver holds the budget. Miss any one of these stakeholders and you have a three leg stool with only 2 legs.
The Last Mile
As the launch date approaches and the ‘product done’ target is in sight several choke points arise. The ones I’ve see most often are:
1. Competitor’s announcements
2. An individual customers demands
3. The product manager’s selected launch date remorse.
A knee jerk reaction to a competitor’s product announcement is often context-less and rarely justified. Properly selected sample customers as part of the product team and effective interview techniques tell you not only what they want, but also what the competition has told them about what is coming. This is not a violation of confidentiality but just an understanding of how an interviewee answers questions based on need vs. something they’ve been told.
Things to ask your customer product team member about a competitive announcement:
1. Does it address the user, chooser and approver
2. Cost of change
An individual customer’s last minute demand is not a launch stopper in a Lean-Agile product team. Why – continuous, synchronous requirements gathering process. A continuously sampled customer’s last minute demand is always, yes always either a corner case or a knee jerk reaction of their own because of unanticipated changes in their target market conditions. Bringing that demand to the customer’s product team members (user, chooser and approver) usually moves it to the ‘next release’ list.
Every product manager for all time has a moment of doubt at launch time. Keeping it to a moment rather than a straightjacket and sedative event is the key. Continuously validating and verifying the product value with customers, channels of distribution, sales, and outbound marketing keeps the remorse to a moment.
Conclusion
Continuous verification and validation of product value with sample customers and market conditions along with synchronous communication with cross function product team members ensures a better quality, faster delivery, and lower cost solution.
There are two spots where products in development most often lose their way. In the first mile because the
initial wave of requirements are 1) vague, 2) context-less, and 3) not from a representative market sample.
The next where-am-I point, the last mile, is where the DONE target keeps moving, often because of unrelated events; for example, a competitor’s product announcement, an individual customer’s last minute demand, and
a product manager’s launch remorse.
The First Mile
Vague requirements frequently happen for 2 reasons
1. A business unit can’t keep up with the requirements pull from a high velocity Lean-Agile development silo and, dare I say, make things up.
2. Requirements come to the development team as a feature list rather than a context sensitive story.
Silos of any kind are a precursor to a train derailment if not a full wreck. This holds true for a Lean-Agile software team silo. The best starting point for a Lean-Agile initiative is with a product team that includes all the functions needed to take a new offering or enhancement from the defined and validated market pull through to launch and life cycle management.
That being said, the vast majority of Agile initiatives start with the software team; and those well managed see, for a time, significant improvements. Then the Agile software silo runs into the rest of the non-agile organization and stalls. Hardware teams can’t synch up, marketing can’t deliver context- validated requirements fast enough and release operations can’t handle the volume of ready-to-go offerings delivered to their doorstep.
We’ll address the hardware and release operations chasms in a separate article.
In the current age of “I know what I want and I want it now” the defined and validated requirements gathering process needs to be done in a continuous, synchronous flow. Continuous because the elements that affect the market condition change weekly, yes weekly. Synchronous because, at that rate of change, the other product team members need to know about changes ASAP to avoid going too far down a path that will need to be backed out of.
Why is context important? The “Here’s the features, build it and they will come” mantra actually never worked. Numerous studies have shown that as much as 60% of product features are not used. Rather than ask a representative sample customer “What do you want?” ask, “Tell me about your day, week, month, quarter.” That way you find out not only what they want, but also how it will be used in different contexts.
Who do you interview: the user, chooser and approver? Why? Context. The user is at the desktop, the chooser, usually a manager, is concerned with team and tool collaboration, and the approver holds the budget. Miss any one of these stakeholders and you have a three leg stool with only 2 legs.
The Last Mile
As the launch date approaches and the ‘product done’ target is in sight several choke points arise. The ones I’ve see most often are:
1. Competitor’s announcements
2. An individual customers demands
3. The product manager’s selected launch date remorse.
A knee jerk reaction to a competitor’s product announcement is often context-less and rarely justified. Properly selected sample customers as part of the product team and effective interview techniques tell you not only what they want, but also what the competition has told them about what is coming. This is not a violation of confidentiality but just an understanding of how an interviewee answers questions based on need vs. something they’ve been told.
Things to ask your customer product team member about a competitive announcement:
1. Does it address the user, chooser and approver
2. Cost of change
An individual customer’s last minute demand is not a launch stopper in a Lean-Agile product team. Why – continuous, synchronous requirements gathering process. A continuously sampled customer’s last minute demand is always, yes always either a corner case or a knee jerk reaction of their own because of unanticipated changes in their target market conditions. Bringing that demand to the customer’s product team members (user, chooser and approver) usually moves it to the ‘next release’ list.
Every product manager for all time has a moment of doubt at launch time. Keeping it to a moment rather than a straightjacket and sedative event is the key. Continuously validating and verifying the product value with customers, channels of distribution, sales, and outbound marketing keeps the remorse to a moment.
Conclusion
Continuous verification and validation of product value with sample customers and market conditions along with synchronous communication with cross function product team members ensures a better quality, faster delivery, and lower cost solution.
RSS Feed