Feature creep and unplanned work are the biggest risks that can delay your launch.
A map shows you where you are now and plan to go. You don't lose sight of the destination when unanticipated events come up. When shipping your minimal usable product (where you start) and ultimate product (where you want to go), use a release map.
What are release maps?
The release map shows how a minimal usable product will improve over time.
Each release will result in a usable product that meets a goal for the targeted user. Let's say your goal is to build a car to go from point A to B.
The first release is a skateboard powered by the human's legs. You can't go very far - but it gets the user from one place to another.
The next release is an electric scooter that allows you to go further with less effort. As illustrated in the diagram, it takes multiple iterations to get to your ultimate vision of the car.
When stakeholders said, “That’s all you have in this version?”. This map tells the story.
Are you a looking to work more effectively with engineers?I’m currently writing a book to address these pain points. As I’m preparing for the next iteration, get it at any price you want. (You read that right — including free).
How to use release maps with a real-life example
All you need is a spreadsheet. Here is a release map I used for our last product launch. You can download it here.
The product allows users to sync their contacts from CRM to Facebook. I will explain what each heading means.
Release version. Name it so that everyone knows what is the key use case or feature included in this release. Just using numbers alone doesn't resonate with stakeholders. After a few more releases, people lose track of what numbers we are at.
Release goal. Highlight the use case that is most relevant for that group of users. For our first release, the goal is to have our internal marketing team dog food this product.
Tester. Who is using this version of the product?
The internal marketing team would be able to sync contacts in our CRM to Facebook. This private beta provides a safe zone for testing. If we screwed it up, it doesn't impact our users.
Assumptions and risks. What is the one thing you need to make sure it works? What is the one thing that if failed will stop you from completing this iteration? Keeping this top of mind during the build phase.
In this example, our team is completely new to FaceBook APIs. So the risk is not knowing how to use them.
Timeline. How long will it take to build this version?
Group related features. Organized by the user flow from top to bottom. If one feature is not included, you know where the user will get stuck.
Features under each group. Work is prioritized from top to bottom. I like to link each feature to more detailed requirement docs, demo videos, or mock-up.
There are several release map formats. Tweak it so that is easiest for your stakeholder to understand.
Why should you use release maps?
1. Focus working on the "must-haves" that matter to your release goal. Scope creep happens when you want to squeeze more in a release. This stems from the fear that nobody will use it without this feature. The side effect of feature bloat means more prone to bugs and more time is needed for testing. It is better to take on less and test the must-haves thoroughly.
2. Communicate progress and change of plans. Most launches have a deadline because marketing needs to prepare launch materials and support needs to be trained. When you sense risks of not being able to complete everything promised in a release on time, you are forced to "cut scope". If they are critical, move it to the top of the next release. So everyone knows you are aware of the urgency and will tackle this first thing in the next release without delaying the launch.
3. Align stakeholders on the scope. The release maps show the first and future versions of your product. The stakeholders will see that the product gets "better" each time. If the feature they requested is in a future release, they know you listened. Whenever you get asked "when can I get XYZ", ask them to refer to the release map and save you time repeating yourself
4. See the big picture and identify dependencies. With the features laying out on a page, engineers working can understand how their features contribute to the broader goals. They can see other engineers' features depend on theirs. If a deliverable is a foundation to multiple features, do that first to ensure it doesn't block the rest of the release.
Sum it up
· Be clear on your goals to get alignment on the "must-haves".
· Adjust release maps to show product enhancements over time.
· Explain your rationale by summarizing feedback, data, and lessons learned from previous launches.