The definition of the product is increasingly recognized as the most important component of a software engineering project. Whereas previously the definition of a product’s functionality often involved a lengthy specification of relatively dry use cases, today the Product Owner/Manager must be ready to provide compelling user personas, epics, stories, storyboard, a UX guide and additional documentation to the engineering team. If that sounds like a lot, we can help.
Honing the Idea
Whether you are a Fortune 500 company looking to release a new feature for a mature product or a small up-start ready to disrupt an industry, you have to refine your idea into something that is buildable in software.
What is Needed? What can be Delayed?
The interactive flow between the product design and its users is a commonly overlooked deliverable by product teams. Often these are either too technical or too fluffy. What’s needed is a practical understanding of how the system will work in reality. This often leads to decisions about what needs to be built first. There are several analytical techniques which support this decision-making process including mapping out existing workflows, as well as thinking through the post-completion workflows of the product.
Minimally Viable Product (MVP)
The concept of a Minimally Viable Product has gained a lot of traction over past several years and for good reason. By looking at the big picture and understanding how each user will interact with the system you can prioritize which components need to be built first to expose the product to the intended users and get their feedback early. You must define what truly is necessary for the MVP and what can be delayed until the fundamental product concept has been validated. At the same time you need to identify the user touch points to ensure that the goal of the software can be reached with the minimum of engineering effort.
Storyboards and Stories
(See Storyboarding)
Often the easiest ways to understand a system is to see written or sketched mockups (wireframes) of what the product’s screens will look like. In that way even non-technical staff or executives can obtain a feel of what the product will do and look like. I’ve storyboarded out several systems (as well as engineered them to completion and/or sale). The goal is always to have the idea come alive.
When you have an overall sense of what you want to build you can then identify your User Personas and create the set of instructions, or narratives, for the engineering team. These are called User Stories. I have been lucky to have defined several systems and have written these stories and larger epics for many diverse systems. I have also worked with more traditional product requirement documents which can work quite well in certain circumstances
Now-a-days I insist on using an online tool to organize stories into features and epic stories, so that you can define larger chunks of deliverable work for your engineering team. These tools will also allow you to monitor the engineering team’s execution progress.
In Matters of Product, Communication is King
Beyond mockups and stories there are several communicative techniques to enhance clarity of what a system must do and how it should do it. This kind of documentation is specific to the problem being solved, but the goal is always to create a shared mental model for the executive, product and engineering teams to use. Without such a shared mental model the teams can drift apart causing costly failures and wasted engineering time.