This is part of our How We Work series of blog posts. Today, we're talking about how we use release planning to understand context, prioritize needs, and create roadmaps. At Very, release planning typically kicks off a new project.
Once we've identified the right problem to solve, we determine realistic, viable paths to a solution — but we also go down rabbit holes and chase unicorns. The objective is simply to generate insights, to understand the implications of radically different perspectives, to evaluate every possible approach to solving the problem. As we start to eliminate paths, we become more confident with each decision because we've explored each alternative.
First priority: prioritizing
Release planning is all about understanding context. We gather the existing information on every critical problem we're solving, so that we can see — and fill — our riskiest knowledge gaps. Then, we start on the most important tasks and work our way down. Given our experience and your expectations, we work together to prioritize application features, classifying everything as a "need," "want," or "desire."
To close the gap between experience design and development, we walk through a workflow mapping process together. This creates specific user activity flows, drives the application design, facilitates critical structure decisions and visualizes the order in which they should be implemented to minimize risk and cost.
The release planning — and any early validation work — leads to the creation of your roadmap. A roadmap is highly technical, highly specific, and highly critical to the success of your product. It contains the major functions of the applications and is broken down into "epics." Every epic is a collection of the individual tasks or feature slices that must be completed for each feature to perform perfectly. Like any journey, your project depends upon having the proper roadmap: it lays the foundation for the work ahead, allowing you to accurately set scope and budget parameters, and serving as the "live" board we will use to track progress.
Man cannot build on Agile alone
Agile is great. In fact, it's the best software development methodology around:
- Agile is designed to reduce the risk of large technology builds, and it delivers on that.
- Agile is designed to be more responsive to competitive pressures and customer demands, and it delivers on that.
- Agile is designed to improve product quality by shipping faster, and — spoiler alert — it delivers on that, too.
But Agile is not enough. Sure, it tells you how to build fast, and with less risk. But it doesn't tell you what to build, or why to build it. This is where lean comes in. Lean is all about is figuring the optimum set of features to produce maximum ROI. For us, life or death occurs in the backlog — not the done lane.
"One of the biggest and most common mistakes product teams make is to have far more confidence in their product specifications than they should, and they move forward and think they'll adjust the product — if necessary — once they get beta feedback. But of course beta is far past the time for major changes, and it is little wonder so many initial product releases are so far from the mark."
Is release planning right for you?
Maybe. Do you need to:
- Develop a phased product roadmap that provides the most value to users, as quickly as possible?
- Understand and document full scope of requirements for launching your product?
- Mitigate project risk through technical research spikes by understanding cost, complexity, and time required to build and launch the features of the application?
- Determine the correct technology stack to support the functionality, design, platform performance requirements, and constraints?
(If you're nodding, keep reading.)
We begin with information gathering so we learn everything there is to know about the business, the customer, and the problems this project will solve. We also expose unvalidated assumptions and knowledge gaps, so we can start managing uncertainty. From there, we make plans to fill the riskiest knowledge gaps and validate, or invalidate, the riskiest assumptions. We also review all existing research conducted and review an analysis of competitive products.
Throughout the session, we work to define the business needs, the end users, and the solution we're bringing those users. We identify the situations in which they will use the product and its features, and we determine their motivations. Together, we decide what success looks like — for the whole project and for customers.
V2MOM & Lean Canvas
This activity represents a lightweight framework for helping focus goals and objectives, while providing an easily digestible way to communicate these to investors and team members. It is articulated well in this blog post by Marc Beinoff: How to Create Alignment within Your Company in Order to Succeed. V2MOM is a quick exercise, but we use it to make sure we understand the larger impact or importance of this initiative from the onset.
- Vision: What do you want?
- Values: What's important about it?
- Methods: How do you get it?
- Obstacles: What might stand in the way?
- Measures: How will you know when you have it?
Lean Canvas or Value Proposition Canvas
We work together during several collaborative sessions to identify and document the key components that comprise any successful business. Lean Stack is a strong place to start. Another great framework to use is to start with a deep understanding of your value proposition.
The customer journey
At this point, we experience the platform through the eyes of a new user who has no context or previous orientation. Then, we start asking questions: How do we get them hooked? What is the point of view we want to communicate? What are all the ways users engage with that POV? What will keep them coming back? How and why will they share their experience with everyone they know?
Needs / wants / desires
We begin with a feature wish list and organize it into columns of priority:
- "needs" (must haves, top priority)
- "wants" (nice to haves)
- "desires" (would love to have someday)
Our goal is to determine which features are critical to the business and customers. It also helps us start thinking how to define the Minimal Viable Product and project scope.
Job stories are the fundamental units of functionality we build and deliver. We think of them as vertical feature slices that stand on their own and add value to the end user. Job stories define a given situation, a user's motivation for acting within that situation, and the expected outcome of the action.
Using the "Jobs To Be Done" framework, we walk through the Job Stories, key activities and flows that users will take through the application. Then, we assemble them into a working list and prioritize them. This is a crucial step in defining the User Experience and User Interface, and it heavily informs the overall design of the application.
Identifying key workflows
Building a workflow map — With any kind of form entry, users inevitably will encounter an error. Because a site map is limited to what's on screen, the presentation of that error and its resolution pathway are often overlooked.
A workflow map, on the other hand, includes real world objects as well as everything that happens off screen, or off the core site map. So it covers not only the "Happy" paths but the "Sad" paths, too — which are a reality for any platform where information will be entered. As we work together we'll be able to identify the individual components within pages as well.
Success criteria and acceptance tests
Working together, we define success for the product from a revenue, usage, and performance standpoint. What are the distilled, quantifiable metrics we can use to measure progress towards success? We also work on converting key workflows into individual, vertically sliced (server, data, interface, usable on production) features. We discuss technical requirements, constraints, and options. Then we force rank them into each feature in the product's development cycle.
Analytics and tracking frameworks
We discuss upfront any technical constraints to gathering data. Typically, we use Segment, a core analytics service for collecting and tracking user and system data. We track user attributes like email, name, location and any other custom properties you can think up. Then, we associate those attributes to events the users perform, like creating campaigns or buying coffee.
Once we integrate Segment into the application and the data is recording properly, we can send that data to hundreds of third-party services (i.e. Google Analytics) without having to update the codebase or perform individual service integrations. It's pretty fancy stuff, and it translates to better data, deeper insights, increased efficiency, lower costs and more flexibility as your business and platform evolve.
Epic and iteration planning
After we draft stories needed to accomplish user goals and business objectives, we estimate each job story with points. Points indicate the complexity of various job stories, as well as supporting detail. We break down more complex stories into smaller ones, reducing exposure to risk.
This provides us a clearer understanding of how much effort is required to build the pieces of the application. We also account for system concerns such as performance, compliance, scalability, fault tolerance, and maintainability. During development we will learn much more about how to build solutions to meet to user's goals, so we will continue refining stories and our release plan.
Product development roadmap
At this point, we look holistically at development needs. We build out a product development roadmap, organized into releases and weekly iterations so that the coming releases are clearly defined. We construct a release plan by sequencing work based on technical dependencies, risk, resource utilization, and just-in-time planning.
We've turned over most stones, and in some cases, performed research spikes to reduce uncertainty and verify assumptions.
Do you like to use these same frameworks and methodologies? We’d love to work with you. Tell us about a project you’re working on.