Businesses, by nature, evolve. Whether influenced by changes in the market, changes in client demand or the ever-changing industry landscape – the products they offer must adjust, pivot and prove value to stay at the top of their game in today’s markets. Naturally, that can pose a number of challenges. Ryan Alford, CEO and Founder of Engineering Design Group, explained how his team overcame the limitations of the company’s product designs as it grew.
Acknowledging the limits of early product designs
“We designed an early version of our product without knowing how that initial design might limit us as we grow our customer base,” said Alford. “Now, the future is here, and some of the design decisions we made nearly two years ago are still impacting how we move forward.”
The problem Alford described is common in early-stage businesses as they shift to serve a growing number of customers. Early concepts and solutions that may successfully serve a single client or user do not always translate to easy scale or intuitive functionality for many users.
“At the time, the product was designed for one customer, so
considering the small customer base, any path forward was reasonable if it brought payment,” he continued, spotlighting the common mindset for early growth.
With growth, though, businesses must acknowledge the limitations of early-stage design and begin to explore the capabilities that will enable products to scale.
Building a minimum viable product
The process that product designers and developers follow often begins with a proof of concept and minimum viable product.
“We had little funding, and we even stripped the product down to the minimum viable feature set for that single early customer. The industry would refer to this as a minimum viable product, or MVP. But in terms of supporting our growing customer base, this MVP was not just lacking the features we would eventually add, but it was architected in such a way that some aspects would need to be redesigned from the bottom up to support our future growth.”
Just as Alford described, the MVP is exactly what its name says: “minimum.” MVPs are perfect for establishing a concept, building a test product and putting ideas in front of friendly end-users that can help to gauge the value and usefulness of the concept in market. Ideally, the creation of an MVP involves minimum resources, minimum investment and includes only the bare necessities as features – allowing for minimal expense in proving if the direction is the proper one. MVPs, though, are not ideal as long-term marketable solutions and almost never possess all of the necessary features to fully serve the end-user.
Alford further described EDG’s experience moving beyond the MVP: “As we have grown, we have learned to live with some of the architectural deficiencies of this core product. But in recent months, it has become very clear that we cannot simply add the missing features to grow the MVP. Many aspects need to be redesigned from the ground up.”
Sometimes, the “ground up” approach is a true necessity – especially when the original build doesn’t allow for expansion toward your next steps. Product development teams will also move systems forward by continuing the product development cycle passed the MVP stage through a series of indefinitely repeatable phases. These processes allow for your product to reach a reliable stage in which it can offer true, proven value to your clients while maintaining the flexibility to evolve over time. At a very high level, these include:
- Minimum Viable Product
- Minimum Marketable Product – Just a step further than the development of your MVP is the MMP. The MMP is an interation of the MVP with “cleaned up” functionality that is satisfactory for early-stage market availability. MMPs are not often prepared for mass adoption or scale, but they are able to prove value among clients and give your business a solid foundation of user experience and development data from which to continue the evolution of your product.
- Alpha and Beta – Alpha and Beta stages often offer early access to market-ready features and functionality in a way that allows for final QA and testing. Clients often opt into Alpha and Beta programs for an opportunity to see what new features are coming to their favorite software and products. In exchange for this “sneak peek,” they understand that there might be a few hiccups in their experience. Many times, they’re willing to offer valuable feedback to your development teams so that you can work out the kinks before a full (and often times expensive) go-to-market launch.
In many organizations, each of these has several sub-phases that continues experimentation, testing and evolution of the product until it reaches the desired state to be shared with friendly testers and clients. With the proper foundation in place, development teams can maintain the evolution of features across the system as a whole – allowing for constant growth and expansion of functionality.
Moving beyond early product designs
As Alford points out, “different team members see different ways to do this, and different times that it is best to do this. But prioritizing changes to an existing product while supporting new customers that need new features is a delicate balance that depends on cash flow and contractual commitments.”
Businesses can thrive when they’re able to find that balance – especially if their teams can find a baseline for communication around the competing priorities of clients, needs of the business and overall innovation.
“There is no perfect path forward, so we work together as a team to understand when it is time to rectify the decisions of our past. One of our objectives is that we only do work that moves our customers forward. And so, our customers have served as a compass for deciding when it is time to add new features versus when it is time to change what we have already created,” said Alford.
Doing it all again
Throughout the product development process, teams review what they’ve created, how feedback has changed it and what goals they aim for the product to achieve. The process is equal parts proactive and retrospective – using ongoing learnings to inform next steps. Following that process, we asked Alford if he’d change anything about his approach to tackling early product design limits.
“Hindsight is twenty-twenty. But back then, EDG did not have any other team members. It was just me. If I could go back to that point in time, with the same knowledge I had, and the same cash flow available to the company, I am not sure there would have been a better path to take. It was ultimately that project that helped transition EDG from a contract engineering company to an OEM with our own hardware and software products, said Alford.
“With growth and time, I think you will always (and should always) look back at the past and ask what you could have done differently. While in this case, I don’t think there is anything that could have been done
differently, this serves as an important reminder that once a product is
created and in use by a customer, changing it can be a big uphill battle.
“So, when you are designing something new, use your resources – your team, your time, and your cash flow – to design it the best way you possibly can for the future.”
