How to “CATCH” an MVP

I was recently asked to participate as a panelist for a startup week event to share my experience developing MVPs (Minimum Viable Products). Ahead of the panel discussion, our organizer shared potential questions so each panelist could reflect and create our responses for the audience. Perhaps because I was focused on the MVP acronym, I suddenly found myself cleverly looking for a way to remember the characteristics of what has served me well as a Product Owner. To my surprise, I began to craft my own CATCH phrase. Literally!

Collaborate – And listen

First off, don’t skip this step. There is no better place to validate your ideas or reign in the scope of a potential project than through an evaluation with your peers. This also allows you to gather a deeper understanding of how this project or idea could impact others within the organization. It’s also the first opportunity to begin garnering buy in and excitement from others so make sure you have done your homework on the value propositions this project could create.

The concept of MVP sounds simple until you gather a group of people to define an MVP. By collaboration, don’t assume you need one gigantically long multi-hour meeting where every major player is invited to contribute. Know the personalities and perspectives you are dealing with to align collaboration opportunities. For example, Sales and Support team members often have very different pain points. Small 30-minute meetings with each respective area of impact will likely be more effective and productive. One hour-long review with everyone as a follow up to the 30 minute meetings will likely result in at least a first draft of your prospective MVP project.

I believe the following should be considered essential to MVP discussions:
sales, support team representatives, stakeholder(s) with vision for the product, a technical architect for in-house solution, and a UI/UX designer.

Ask Questions – Don’t just ask, answer them

Once you have crafted an initial draft, start asking questions. Increase the exposure of your MVP concept to a sample of customers. I highly recommend working with a UI/UX designer to complete some wireframes ahead of time. Humans in general are exceptionally visual people. Words don’t often paint a good enough picture, especially if the solution is complex in nature.

What are some important factors to consider answering?

• Time to market – How quickly must you respond to the problem to be relevant? How quickly could you feasibly develop the solution?
• Return on investment – How quickly can you get a return on investment and can you further reduce the scope of the MVP to minimize risk?
• Market penetration/demand – Is the problem you are solving always going to be there? What could change in the future?
• What is the biggest risk and can it be overcome or minimized?

Answering tough questions is vital to understanding the value of the product. The product owner will likely be forced to decide between various bells and whistles. Value is always in the eye of the beholder. To use the classic PB&J sandwich as an example: the sales team is concerned about the type of jelly, support is focused on the bread, and the customer really wants a particular type of peanut butter. It’s a balancing act, and understanding the true value of how you are solving the core problem will assist the product owner in making well-informed decisions about priorities and potential phases of development. Perhaps you will completely miss the mark if it’s not strawberry jelly, wheat bread, and crunchy peanut butter!

Talk-sell ideas to everyone and set expectations

Hopefully by this stage you have received the validation needed to move forward with your MVP. Now, what is THE most important aspect on where to draw the MVP line? What about your solution at its core solves a problem or creates the most value? Can you break the solution apart into phases to minimize risk and plan to provide incremental value in each future phase (think “Fail Fast”)? I’m sure you’ve heard this from every sales person ever: “A phased approach won’t work. If we don’t have it all, the product will fail.” That’s not a great agile mentality, but that’s a topic for another day!

Bring your core collaboration team back together and talk through the possible phases of development. Have tough conversations about what you Must Have, Should Have, Could Have and Won’t Have. Try to limit the first phase of development to only the Must Haves. Get creative about how you might address the other features, even if it means there will be some manual, less automated processes in the short term.

After talking through the phased approach, set expectations with both your team and customers on how the product and features will roll out. Good customers are willing to wait for features if you are transparent and have done a good job addressing the primary pain points in phase one.

Change – expect & embrace

Once your vision is defined, you now have to build the darn thing. You have the plan. You have set the expectations. Then your first derailment happens.

That sales person who said it was all or nothing just promised a feature that wasn’t part of the initial phase, and now you have a client willing to pay premium that will jumpstart the revenue for the product.

What do you do?

First off, don’t freak out. Expect change and be prepared to embrace it. It’s an inevitable part of the process, but how you handle it is key.

Considerations
Jump on a call with the customer and sales person. Make sure the customer has a good understanding of the current roadmap and expectations to which you are trying to adhere.

• Is what the customer wants a must-have requirement?
• Is this the first time you have heard of this issue, or does it already exist on the roadmap in a future phase?
• What’s the impact of the change? Loop in a development lead to get an idea of potential issues this feature may cause.
• What’s the increased cost? How long would this delay the first phase roll out?
• Verify the issue with another prospective customer. Is the derailment worth it?

And this is why they call the product owner the “single wringable neck”.

Humble – Be a servant leader
Hopefully you are surrounded by a culture of people that typically implores being a servant leader as a way of doing business and life in general. When developing something new and nebulous, it’s sometimes exciting but it’s also nerve racking and uncomfortable to those involved or who have a vested interest in the product’s success.

Communicate and fill the gaps
Major players should be looped in and on the same page throughout the process. If you see a gap or feel something needs to be done, do it yourself or work with the right party to get it done. Surface issues or misunderstandings immediately. Don’t let things fester or go unexplained.

Don’t make an ASS out of U and ME (Assume)
Team members should humble themselves to whatever the team and the project need. This is not one person’s job. And “team” doesn’t mean only the team doing software development.

You’ve done it. You’ve finished your MVP. How do you know when it’s successful? How do you truly know why? How do you know if it bombed? Why would you guess so many MVP candidates miss the mark?

To name a few culprits: overbuilding, overcomplicating, distraction and not enough strategic focus, and improper planning at the beginning.

While I can’t guarantee success by following my “CATCH” phrase, I can tell you that these principles have worked. With that said, I have also experienced my own share of failures where products released to market were pulled out after a year or two and even completely rewritten.

There isn’t a perfect prescription for creating a successful MVP. Having an agile mindset to remain focused on delivering continued value and constantly evaluating when to pivot in response to an ever-changing market will be vital to keep any product going. Cultures actively embracing servant leadership and the discipline to resist distractions will also help ensure the long-term viability of any product.