Building MVPs for Ops Products
Weekly musings about life as a PM
You’ve probably seen some version of this graphic of how to build an MVP.
One key reasoning behind this is that while it’s important to get a good understanding of the problem and to engage in discovery, learning happens best after your product has been deployed and is being used.
Over the past week, I’ve been starting to wonder if this can also apply to operational type products. Some challenges that might be encountered when building such products:
- Changing operational processes to optimize workflows and cater to scale while the product was built to support operational flows at a smaller scale
- New services being introduced that require new processes that the product cannot currently support
- Differing processes across markets that are still in the process of being or yet to be standardized resulting in customized logic that is built for each market
So what are the downsides of an MVP approach?
- Local optimizations vs global optimizations as features solved for problems in specific parts of the flow as compared to relooking the entire process and optimizing it as a whole
- “Imperfect” product that doesn’t support all operational workflows which results in operational workarounds and slow down product adoption
Does this mean that should be abandoning the MVP and going back to traditional SDLC ways of building products? I don’t think so. A PM is rarely given a few months to just do discovery work and plan out what the ideal product solution is going to look like. Even if you were given that time, ever-changing processes will mean that your solution might no longer work. If you’re in a similar situation, here are some things I’ve learnt or keep in mind:
- Being comfortable with incomplete information and change. A feature that you built initially might need to be tweaked a few months after to accommodate changes in processes. (This is painful but if a skateboard and car don’t exactly share common parts.)
- Planning ahead. Be aware of plans for the future to factor in potential needs when deciding how a feature should be built. This will help to future-proof your features to a certain extent.
- Listen and respond to feedback from the ground. This helps with identifying opportunities to improve the product. Regular improvements improve the end-user experience and can aid in product adoption.
- Patience and alignment. Some problems might require alignment across multiple teams in order to be solved. Not all teams might be ready to address these problems and so figuring out the right time to start the conversation is key as well.
If you’re also working on building products for operational teams, have you faced any challenges with building MVPs? Have you used any processes and frameworks that have help?
