Over the last few posts, I’ve discussed how the MVP method is very frequently referenced but rarely used, and there is a good reason for this. It’s not easy. There are many tall obstacles to applying it successfully. My previous post described how the organisational structure can challenge the process. This post is about an obstacle that may be easier to change, but sometimes more difficult to recognise: You.
You want to be a visionary
Most organisations look for product managers that have a strong understanding of the market, the product, the industry and the business itself. This knowledge combined with “vision” is expected to define the future of the product, including features that will deliver the results the business is looking for.
The problem is that the MVP method demands flexibility. You must focus on learning as much as possible while building the minimum possible at every step, and then reacting or pivoting based on what you learn. This can mean that the original feature list changes multiple times based on user response, unforeseen technical challenges or other information that is uncovered along the way.
It’s difficult to accept that your vision was wrong. It’s even more daunting to have to communicate to your boss and stakeholders that you, or worse they, were wrong. This can cause you to adopt attitudes or behaviours that hinder or block your project from being successful, such as:
- Inability to see the assumptions that need to be tested. Do my customers want this and will they use it are the most important assumptions to test, and must be tested regularly, and yet these are frequently forgotten in the rush to build features
- Resisting the testing of assumptions, instead insisting that the market research or domain experts are enough
- Becoming attached to features, or continuing to deliver stakeholders’ requests and not pivoting or changing priorities when the information learned indicates
- Enacting a “cone of silence” when features aren’t testing well or have been removed from the scope, in order to avoid facing the people who requested them
- Pushing your team to deliver more than what is needed, so you can awe and amaze your stakeholders when you reveal the new feature.
You want to deliver on time
The MVP method emphasises building the absolute minimum possible while learning as much as possible. The focus is on building the best and smallest viable product rather than delivering a (potentially) less viable product on time. Unfortunately testing assumptions and learning can take time.
Whether you are a project manager, a product manager, a functional manager, or a member of a development team, you are always under pressure to deliver according to estimate or by a specified date. This pressure can lead to short cuts, like:
- Emphasising delivering features according to the schedule rather than learning and delivering results
- Avoiding pivoting or ignoring feedback because it will throw off the schedule
- Accepting or committing to delivery dates too early
- Building features that were requested but have not been tested
What can you do?
As any support group will tell you, the first step is recognising that you are the problem. And let’s face it, we’re all guilty of the above from time to time. The next question is how can you improve? Here’s my six step program to improving your part in the MVP method:
Be vigilant about minimising the work. I know that as a Product Owner, I often find myself asking “Can we do X? Will that fit in the time frame? Can the technology deliver it?” What I don’t ask frequently enough is “Do we need this? Do we need it now or can we get it later? Is this the minimum we can do? What does this help us learn?” Remember these questions when you’re next discussing UI and UX design.
Be transparent with… well everyone. This includes your team, your boss, your stakeholders and your customers. Don’t just tell the good news, you need to tell people the bad news, and the neither-bad-nor-good news. Most importantly, explain why decisions were made. Why did you decide to axe a feature? Why did the priority or focus change? I also recommend that you communicate this face-to-face and informally as much as possible. Presentations and emails don’t elicit the same discussion and exchange of ideas.
Emphasise results, not features. Define clearly what the business goals are, how your tactics relate to those, and then discuss features that are planned to execute those tactics. Your project must be driven by numbers, not by a list of functions or tasks and a delivery schedule.
Stand strong with the method. Know why the MVP method works, how it works and when it doesn’t work. You will be challenged regularly. An old colleague of mine used to describe this as “killing them with logic.”
Emphasise learning. Remember what Eric Ries says – “…collect the maximum amount of validated learning about customers with the least effort.” I extend this to include learning about your product. A new feature comes with technical challenges, many of which will remain unknown until you start building. If it didn’t, it wouldn’t be new. Build the minimum that allows you to learn as much as possible. Then look for the next lesson, and build a little more.
Check your ego at the door. If you read the above carefully, you will see that you’re going to be wrong sometimes, and you’re going to fail sometimes, and you’re going to have to stand in front of your peers and tell them. Possibly repeatedly. This is hard to do, but you won’t be successful if you focus on avoiding or hiding your failures. It is also important to remember that good ideas can come from your team, your customers, your kids or the cleaning staff. Product development is a team sport. It’s not all about your vision.