Building the Right Product
Project to Product Thinking Part 3
Dating back to the early 2000s the Agile movement drove tremendous advancements in process maturity. We learned to work and deliver in iterations, and focus on progress. But what’s the next evolution of Agile? How do we evolve and continue to increase our speed and adaptability?
There is a better way to understand and tell the product story. There is a better way to create roadmaps, backlogs, and stories. We won’t necessarily find that way in the pages of our methodology’s documentation, but we can certainly fit it into whatever methodology our company has chosen. In the end our process will be stronger, and more importantly, our product will be too.
It all begins with early discovery. At this point we consider delivery to be understood, constant, and largely predictable. So it’s time to turn our attention to answering the question, “Are we building the right thing?” Before we can know if we’re building the right thing, we have to know how we build. How do we bring products to life?
The Early Discovery Period
The official start of an agile product initiative is the discovery period, typically lasting one to two days. During that period, four questions should be answered, and done so as a full product team to ensure a common understanding:
- What are we building?
- Why are we building it?
- Who are we building it for?
- How are we building it?
Discovery can begin with pre-prepared ideas or as a fresh brainstorming session. The key to identifying which ideas should be pursued is how effectively those four questions can be answered. The ideas with viable and productive answers across all four questions are worth moving forward with, while the others should be scrapped or deferred to a later discovery session once new information is available.
The result of early product discovery is a list of prioritized experiments that are worth investing time and resources into, also known as our product backlog. The initial product backlog may only include a few dozen stories to start with, but it’s enough to engage a new product team and give them valuable productive work to start on.
How do you bring ideas to life?
Establishing Your Product Team
Your product team should include members focused solely on delivery: front-end developers, back-end developers, and testers; as well as members dedicated to ongoing discovery: product managers, product owners, and analysts.
Most importantly, there will be at least a few team members involved in both aspects of the product development process such as, technical leads, a lead QA engineer, or designers. While their focus is writing and testing code, they’re also in a prime position to share information back and forth with the discovery members about their work.
Take note that discovery and delivery are two different activities with two different cadences, but done by the same product team. If we separate the discovery and delivery teams, we’re creating a handoff between product and engineering, or business and IT. A successful product team is centered around one product and everyone on the team should feel a sense of ownership for that product with the goal of solving customer satisfaction problems as one unified team.
Once your blended product team is formed and starts working on the initial product backlog, a feedback loop is immediately established between delivery and discovery with delivery constantly considering:
- How will we build this?
- How much can we build?
- Are we building it the right way?
and discovery constantly considering:
- What problems do customers have?
- What value can we create for them?
- In what order should we create that value?
- Did we build the right thing?
Putting it All Together
Now we can start to look ahead and dive into visualization of the product story and identifying journeys throughout the product story. Let’s take a look at the whole process:
The discovery group starts by grabbing that next journey off the backlog and authoring it to add a description that answers the questions “who”, “what”, and “why”. Next, acceptance tests are added at the journey level – cross-cutting tests that describe the behavior we expect the journey to deliver written in test language in order to be verified.
With a general understanding of what this journey is and what we hope to accomplish we can take on some of the cross-cutting concerns as a discovery team. For example, do we need to create some sketches of the user experience? Do we need to understand some architectural pieces? Do we have larger constraints to deal with?
Finally, we go back to our story maps and determine what stories we want within this journey. It’s likely that we’re just working with titles at this point, as we need to author all the story’s details.
The rest is a repeat of the above for each story in the journey. Once we have authored descriptions, defined acceptance tests, and reviewed these stories with the larger team to assign sizes, they are ready to be worked on within a sprint.
This process is continuous from story to story within a journey, and from journey to journey within the product backlog. New stories and journeys will be created, and when product learning happens, you can adjust the product backlog without having wasted all your hard work. The product now wholly encompasses the new features, the technology, the maintenance, and the legacy aspects.
Conclusion
We want to produce what people need, but we also want to do it in a way that is sustainable. The move to product thinking brings a team of people together with a shared product vision. They all have the same information and have the same love for the product, the customers, and the market.
Projects are linear. Once projects are handed off to another team to start the build of the product, a piece of the product story is lost. Products are cyclical from planning, to funding, to how you organize your teams around the product build. The shift to product thinking enables us to adapt to change, adjust as we learn, and respond to the market. Product thinking leads to a better return on investment and allows us to move faster because we’re building less of the wrong thing and more of the right thing.
Cprime’s Product Agility solutions help product teams get from planning to launch faster. Learn how you can gain more responsiveness to market and obtain higher rates of return from your product investments through our teaching and coaching.
