Ruthless prioritization on a project is not about managing scope or budget. It’s about making sure we focus on what is important, what will add value to the users by getting an MVP to market as fast as possible. What makes business successful is having products that users love and only they can tell you what it is.
When building a new product or platform, there’s a wealth of features and ideas that’s generated from the business and the teams working on them. It’s never ending, forever growing. We could do this, we could do that, this would make the users’ life easier, etc. And, oftentimes, it distracts from what is actually important: why are we building it? Who are we building it for?
Have clear goals and objectives
Define your North Star metric: what is your product attempting to achieve? Once your North Star and other crucial metrics have been defined, agree and commit, this is your direction and what you should remain focused on moving forward. It doesn’t mean that your North Star metric cannot change or evolve.
When delivering a Lean project, short release cycles are all that matter. You need to get your product in front of users to get their feedback and validate your hypothesis.
The North Star metric is there to keep you focused on what’s important and help you prioritize important features and filter out what’s not meaningful enough to make the cut. Moving forward, each release should have a goal that directly impacts your North Star with an initial focus on validating your riskiest assumptions.
The art of staying focused
- Identify the main User Journeys of your product and start by building just enough of them to validate your hypothesis
- Identify the edge cases and evaluate the probability that a user has to end up there
Deciding whether you want to build against an edge case will depend on how significant is the pool of users that’s going to end up in that edge case and, solving it will depend on how much time it will take away from other features that would contribute to your North Star.
Once you’ve made a decision, log it and commit.
The art of saying “No”
In order to remain focused, Lean projects require discipline and that means being able to say “no.” This is something you almost have to do on a daily basis whether it is with the client or your internal team.
Personally, the most difficult part of saying “no” to somebody is when they bring a very valid point or a brilliant idea. Even if those can be very valuable to the product, if they are not directly and meaningfully impacting the release goal or your North Star metric, you have to be able to say “no.” In some instances, adding it to your backlog because this is something that’s high value and could find a place in a future release can be useful or, park it in an “idea box” if it’s something that would come further down the line past your MVP.
Saying “no” to someone is not an easy thing to do and you don’t want to make them feel discouraged to bring other things in the future. When I have to say “no” to somebody I try do a few things:
- Acknowledge the idea is good and when applicable, how it does actually benefit our North Star;
- Explain the reasoning around saying “no,” for example it doesn’t impact the North Star meaningfully enough to look at immediately compared to our current backlog or, it is not required at the scale of the product, etc.
Things I oftentime say “no” to would be:
- UI/UX optimization: if it’s not broken, it probably won’t impact your metrics meaningfully enough or help validate your hypothesis
- Edge cases: when launching your product at a small scale or in a controlled environment, the amount of users impacted (sometimes blocked) is not going to really help you validate or invalidate your hypothesis
- Getting things perfect and depth in functionalities: oftentimes, getting things 80% to where you want to be is fast and enough to validate your hypothesis and the last 20% is just consuming time that could go towards other hypotheses we would like to explore
Embrace chaos and change
You do want people to bring new ideas to the table and, hopefully, often, they will be very valuable to the product and you will have to revise your priorities. As you want to have conversations with the client as frequently as possible, reprioritization will happen very frequently.
That means every team member (client and internal) has to be comfortable with chaos and change. You have to be comfortable with the fact that something agreed upon one day may change the next day. Team members have to be adaptable.
Lean projects are not in the business of planning, having sprints groomed and prepared and executed on. No, Lean projects are focusing on “what’s the next most important and valuable thing we can do right now.” Your priorities have to be organized in a stack from riskiest and highest value at the top to lowest value at the bottom so that your development team always knows the next thing to do after they’re completed their current task/feature.
Conclusion
To summarize, prioritization in Lean projects is not a means to manage scope and budget, it is a tool you use to ensure that you remain focused and deliver fast towards a MVP that will help validate a hypothesis and market fit.
It requires a lot of discipline and having your team embrace the inevitable chaos and changes they will encounter.