The “Can I live without it” mantra
How five simple words can help you slim down product releases
Words are a Business analyst’s most significant assets when trying to break a product into its functional components. When you start working on a new product, the Discovery phase will always generate ideas over ideas, becoming increasingly wilder and wilder, more challenging to figure out where to put them, how and where to start with the analysis, and in what version they should come.
What if there were a set of words that you could use to trim down the scope when used as a mantra to analyse features. I found these words best for products with short release cycles, and they are: “Can I live without this feature?”.
We stumbled upon these words almost by accident when we worked on a product and were halfway through the Discovery phase when we found out that what we thought was the right MVP candidate would take months more than the scheduled product release. We went through the usual prioritisation mechanisms of MoSCoW and the Eisenhower matrix of priority, and they still did not cut it. We needed something else that could work in combination with either of the workshops above and act as a tiebreaker.
Together with the team and the PO, we came up with a fun little workshop we built around the statement ”Can I live without this feature?” that helped us trim down the MVP and make it on time.
Start with a high-level plan
Have a discussion with the product owner for the first workshop in the discovery phase where he/she explains the business context and, most importantly, the problem that the product aims to solve.
We took this step, and once we knew the direction and the problem, we started listing must-haves from the product, supplied by the product owner, and added them all together on post-its on a wall. The exercise can work in an online environment, and you can use one of the many tools available: Miro, Mural, or Lucidspark, for instance.
Finding out what other features could support the Must-haves of the Product and adding them to a high-level backlog is the next step in building the backlog. To produce a high-level backlog in a relatively short amount of time, the teams I worked with and I began to shift our attention more and more towards the technique of Storyboards.
For Storyboards, I like to add as top-level all the steps that the user requires to achieve a specific goal. Below all the steps I like to add the tasks needed to complete them. The result is a slightly turned on its head mindmap and is a step closer to an estimable backlog.
Building the workflow in one place allows us to capture plenty of requirements and place them quickly on a temporary backlog. At the same time, the must-haves can always be front and centre. We usually use a different colour for the Must-haves as they will stand out more in the upcoming prioritisation workshops.
We have most of the items in a backlog; now what?
The next challenge for the team usually comes in selecting what backlog to build. We like to add the features we are building in a pyramid and then group them based on some feature category. The feature category that I like to use will differ from one product to another, but the ones below can be used for most of them. We are doing this while also drawing a slice across the pyramid to emphasise that our time is limited.
The outcome of the workshop looks something similar to the above, just more filled with sticky notes. This helps both the team and the product owner visualize that the time we have to build is limited. This works better online as it works best if you can duplicate the backlog for this exercise instead of moving the backlog items between the two exercises.
You’ll find that this approach is mainly suited for larger applications with quite a lot of flows, and that you can build parts of every flow without much compromise. This works when you have more user personas that can benefit from this vertical approach.
When deciding what to fit in the MVP slice, you cannot slice through the following categories of features: items that can or will fix or avoid technical debt, usability and a good UI, or some features that the marketing/sales team will require. These features should be outside the scope of this UI, maybe with some exceptions.
Crack your fingers for the analysis phase
This stage is where the typical analysis process, and the fun for the Business Analyst, begins, as you get to deep dive into the details of how the product and every piece of the product should work. We’re set on the horizontal style MVP, and we start refining the user activities from left to right. By reaching this point, the backlog state is in a detailed enough estimate to start refining the stories with the team and estimating them.
Order your backlog in a logically consistent manner
A clean backlog reflects a clean strategy and product vision. Having it in a messy state will cause delays and will cause extra work in the planning meetings.
Having the backlog in an orderly fashion will make it easier to start your surgical work on the backlog. What you should do is give your MVP a goal. Make it as straightforward as possible and easy to understand. Do not forget to communicate and discuss the goal with the team and stakeholders. This way, everyone will have the same understanding of what we are building.
Once we set our goal, it is time to start looking at the backlog. We are not subjecting anything that helps us achieve the MVP goal to the chopping board of features. We must keep the sellable features in the product backlog. What must be analyzed from this perspective includes everything else that does not fall under this category.
What we are doing is we are taking every other feature and, while looking at the personas for the application, we ask ourselves the question: “Can I live without it?”. This question should always be from the user’s point of view.
The answer must be either “Yes” or “No”. We are doing this in a workshop or a meeting after we tried some other means of prioritisation. However, at times you will find out that having only two answers is fairly impossible. In these cases, what usually happens in the team is a hearty debate, whether the feature discussed is actually needed or not. What we found particularly useful is adding “for now” at the end of your question.
For some features, this might be easier than for others; the “for now” part of the question ends up being the tie-breaker.
You need to assess the “now” part if the answer to understand the flow you are trying to create may not match the MVP goal. If your goal is to create templates, you might postpone the deletion or edits if they come in rapid succession. Postponing them for now will even allow you to measure the engagement of your users with that feature.
Validate your MVP
The resulting features, regardless of the completeness they are in, must be validated. This means a meeting with the PO and stakeholders on the one hand and a meeting with the users on the other. Meeting with both spectrums of stakeholders will help you figure out whether you are building the right MVP. I like to ask colleagues from other departments to test the MVP's viability; we are usually testing the features versus the workflow.
I like this approach because it can be used in combination with any other prioritisation techniques, as it is usually a step that you do after everything else fails. This prioritisation technique can also be used as a standalone workshop or meeting, making it a versatile tool for slimming down your backlog.
Just as a word of caution, once you start slicing down the backlog, it becomes slightly addictive. Keep your eyes on your MVP’s goal, and when the time will come on your Product goal — good luck building great products and outstanding backlogs.
