Now is the time to look at what that means for the specifications we're responsible for as PMs.
"Classical" PM wisdom tells us that the Product Manager is the owner of the "PRD" (Product Requirement Document) which is a, sometimes very large and detailed, Word document describing all the functionality and features of the new product.
|Thanks to Tom Fishburne|
The big problem with this process and the resulting document is that it is based on "Waterfall" thinking. A thinking that was developed in the 50ties (yes - the fifties ... 1956 to be exact) and abandoned soon after formulation and have ever since been used as the prototype example of how *not* to do specifications. Especially software specifications.
Why is it then that most organizations tend to continue to base almost all their development efforts on this model (and the associated "Stage Gate" model)?
Because it is easy! Waterfall is a simple and intuitively understandable process that makes followup straightforward: "This is what all stakeholders said we needed, this is exactly what we developed, so all is good?" No! - a less polite person might refer to this line of thinking as a "CYA process" ... (see my post on KPI's)
But real PM's are brave people always ready to break new ground to pave the way towards a future that is much better suited for their customers and products. Right?
I have therefore tried to outline an alternative and very simple process to get you started on the Agile path towards this magnificent future:
1. Create an Initial Use Case.
This involves a description of the user experience you want to provide in terms the/a user will immediately understand.
2. Create a first interactive prototype.
With limited functionality but with a clear user interface to enable testing of the user experience you've described. I've found Powerpoint to be a tool you can use but there are of course a wide range of other tools out there to help you depending on what type of product you're trying to develop. A physical item? - try a 3D printing service. A mobile app? - try app platforms as for instance Appery.io. A website? - try Drupal or Wordpress, etc. etc.
3. Test it with real customers.
Perform structured user testing with detailed collection of data. There are many methodologies to do this without affecting the outcome. It is important that you get as honest and direct feedback from the users as possible.
4. Iterate 3.&4. or even pivot as needed!
5. "Raise" prototype to first product.
The first product release is the first version of the product that contains exactly enough functionality to convince first customers to pay for it - also referred to as the "Minimum viable Prototype", MVP. Remember not to give it away for free - non-paying customers are not customers, and they have a tendency to focus your attention on the wrong things. Basically if you cannot even get one of your identified early adopters to pay for what you're planning then it is probably not worth as much as you thought.
Sounds simple? Actually it is, and it is a much more fun way to develop solutions than to spend endless hours perfecting a document that will not even get you to the solution your users need!
Remember it is developing with users ("Co-creation" is the buzzword these days) and the interactive prototypes and focused effort to get to Minimum Viable Product as fast as possible that must be at the center of this process.
Let me know what you think? What am I missing out?