Recently, we’ve been taking a new approach to product development at Arena.
Traditionally, our main goal in developing new product features was to go-live with well-architected, fully-designed and ready-for-use products. While this approach has worked well for us over the years, changes in software development and delivery have got us thinking a little bit differently.
Moving to a minimum viable product strategy
When it comes to product development, our established process was to brainstorm all the ways in which the product or feature could be used, construct a list of requirements that addressed every possible scenario with a range of solutions and implement a design that met as many of the requirements as possible.
This approach came with a few downsides. Occasionally, we missed a key usage or requirement, and even more frequently, we would over-engineer for a minor use case. Although we could achieve a high level of completion and scalability, it was hard to revise or revisit more fundamental aspects post-release.
When Steve Chalgren joined the Arena team as vice president of product management and strategy, he pushed us to rethink our approach. He pointed out that as a SAAS company, we could do things differently because customers are always able to use the latest version of our product and we can iterate rapidly. Steve advocated, and we adopted, the idea of releasing minimum viable products (MVP).
Avoid over-engineering with an MVP strategy
If you’re not familiar with the concept of MVP, it’s essentially the strategy of developing a concept just to the point of usability, and then letting users tell you where to add the bells-and-whistles. It’s a response to the challenge of over-engineered products that don’t do exactly what the customer wants, but it’s also a way to save time and become more efficient, as it is harder to go back and iterate once you’ve put so much time into a fully-designed product.
The minimum viable product model has allowed us to be more customer-focused, and to be a more agile player in the new software development landscape. We’ve used the MVP strategy to release three new targeted applications at this point—PDXViewer, PartSaver and Drop Box. Each of these products was built to satisfy a specific customer need, and while the first release supported some usages, it wasn’t a catch-all.
But that’s sort of the point.
An MVP strategy means that instead of developing a product to its full potential before the release, we’re putting it out in front of customers as a concept, and then letting them tell us where they find the greatest value so we can maximize the effectiveness of additional development efforts.
How MVP strategies allow users to influence product development
So far, this approach seems to be working. When we released PartSaver, one of our early adopters told us his organization used a very similar form for new part requests. We hadn’t come up with the idea of using PartSaver as a part request form ourselves, but once we got this feedback we realized this was an important use case and it has informed the way we’ve developed the product going forward.
Another example of the MVP strategy can be seen in our recent addition of QR codes for SmartLinks. In this case, all we’ve done is allow you to create a QR code. We’re not telling you where to find your scanners, or how to use QR codes in your business, we’re just waiting to see where you might take it.
Developing with an MVP mindset has been extremely rewarding, and I think other companies could potentially benefit from this approach.
Some considerations if you’re looking to implement a Minimum Viable Product strategy
Effective MVP products demonstrate purpose and provide value—even in their most limited form. A group of users should be able to come back to use an MVP again and again even though they think it could be better. This early adoption and feedback is what allows you to iterate based on what customers are doing.
Speaking of early adopters, don’t burn them with a bad product. MVP products may be incomplete, but they’re not low-quality. Remember—that first set of customers forms the market’s impression, so make sure they have a positive experience, even if you leave them wanting more. MVP isn’t a good fit for companies whose products can’t support in-place upgrades. If early adopters are forever stuck with the MVP while future customers benefit from updates, loyalty and adoption for future products will quickly decrease.
A MVP strategy is only possible when you are able to iterate quickly based on user feedback, and when you are confident in your ability to work quickly yet maintain a consistent level of quality. If you release the first version, and find out that customers hate a feature, or that another feature doesn’t work, you need to be able and willing to listen to those concerns, and make changes in a timely manner.
In a successful MVP strategy, the cost customers incur for updates and improvements must be low. In Arena’s case, we are able to push updates to customers quickly and transparently with minimal customer interference since we aren’t an on-premise solution.
A final word on MVP
If you can make it work, surfacing products and releases very early and letting them mature in the public eye allows you to target improvements around actual usage. You dramatically increase the efficiency and effectiveness of your development efforts, and provide your customers with a product that is just right for their needs.