Minimally Viable Product Building
Why build an MVP (Minimal Viable Product)
If you’re reading this article, you are likely interested in MVP development. You probably already have a general idea of the MVP — after all, it’s the minimal amount of product you need to build. Right?
Yes, but what is more, and maybe more important, is that the MVP is just one step in the journey to build and commercialize a product.
While building a successful MVP requires a wide range of skill sets, you don’t necessarily need to hire someone for each role. Rather, you need someone who can act as the defacto resource for each.
I am passionate about debunking the myth that all you need is to hire a couple of developers and code, code, code.
Your approach to executing MVP development sets the tone for how you and your organization continue to develop throughout the product lifecycle. During the MVP build, you are are simultaneously building foundations for the product you sell, setting up internal processes and frameworks for making product decisions, and running a healthy product and engineering organization.
While there are several options ranging between the “two people in a basement” approach and what we’ve defined as Engineered Innovation™, I’d argue that the “two people in a basement” is simply a worst-case scenario of an outsourced development partner. In this situation, if you write some specs and hand things off — 9.5/10 times, you aren’t satisfied with the “product” you get back.
On the other end of the spectrum is staff augmentation. In this model, an organization provides developers and resources to your company to manage itself rather than providing full-service design, product, and development.
For startups with limited resources, the Engineered Innovation™ model (illustrated above on the right-hand side) is more compelling. Having a build partner with a proven process and SDLC, like the Engineered Innovation Group, is essential so customers don’t have to reinvent the wheel.
We help startups go from 0 to 60 in weeks versus months.
Why we are so passionate about building MVPs
There is magic in taking an idea, going through the design process, getting user feedback, and building and delivering working software into users’ hands.
This process is certainly not for the faint of heart, and if there is one lesson I’ve learned in my 18 years of building products, it is that resiliency is key. If you give up when you inevitably hit a setback and don’t get back into the game, MVP development is not for you — in fact, I’d argue entrepreneurship is not for you, but I digress.
10% of Innovation Matters
Here at EIG, we talk a lot about the 10% Differentiated Innovation. That means we want our partners to spend as much time and energy thinking about what truly sets them apart and what needs to be built to realize that differentiation.
When building a team or choosing a partner, I recommend looking for folks well-seasoned in constructing products from the ground up. Seasoned partners can take care of the essential parts of building a digital product so executive function can be reserved for that special 10% of differentiated innovation. Spend your design and strategy money on what differentiates rather than on a person or firm who will need to “figure out” how to tackle those areas that are often table stakes to market entry.
For example, every software app needs security, authentication, support privacy regulations, navigation, a deployment and release pipeline, code scaffolding, etc. Those things are not differentiating (unless your product targets one of those things) but they are must-haves. Without them, you have no product! As such, it’s essential to choose a build partner that can remove those more menial obstacles on the way to innovation.
Prototypes, Steel Threads, MVP, MMP, and Version 1+
We often talk about MVPs, but the MVP is only one step in the product development lifecycle. In fact, before building an MVP, it’s often very helpful and prudent to build a prototype in the form of a clickable design prototype or a solution on a low-code or no-code platform. The purpose is to get validation of the product capabilities as early as possible before investing resources into building the actual product.
The chart below outlines what you should focus on building during each phase of the product development lifecycle and the services that can support those builds.
Prototypes are most necessary Pre-MVP. In this stage, it is helpful to also build and refine your pitch deck, which should include a problem statement, a narrative demonstrating how your product fixes the problem, information about your team, your brand, a simple demo of your prototype, your go-to-market strategy, and the business model that will support it all. Product and visual design are crucial at this stage and ultimately inform what will be built during your MVP build.
During MVP development we break down what exactly we are building into two frameworks — Steel Thread and MVP capabilities. Ideally, the MVP should support your ability to raise a seed round of funding and be enough product to show traction in adoption.
A Steel Thread is a term borrowed from engineering that simply means “the minimal functionality to demonstrate a use case end-to-end.” This does NOT encompass your full MVP scope — it is the MVP’s starting point. The goal is to have a downloadable and demo-able version of this steel thread that stakeholders can use to show off the product and start providing feedback to the team as quickly as possible. During MVP capability development, we build on top of the Steel Thread, using it as the anchor point for the product and adding the remaining features to get to full MVP capability.
Finally, in POST MVP, we build your Minimally Marketable Product (MMP), which is the set of capabilities that are compelling enough for someone to whip out the credit card or sign a contract.
Then the V1+, which encapsulates all the iterations afterward. We can cover what happens from here on a different day.
Pitfalls
The outline of the Engineered Innovation™ process may seem straightforward — sometimes, you were nodding along. What is just as important in the process for us is also designing each step to avoid these five common MVP development pitfalls. Below we’ve explained these pitfalls that are so easy and normal to occur and what we are doing differently to help our clients avoid the traps.
Building too much too early
The bigger the footprint of a product, the more that has to be supported! More complexity is required which means more things to test, support…and that can break. We continually and frequently review development progress and ask ‘what can be cut’. Edit. Edit. Edit.
Being surprised by how long it takes to build
There are going to be tradeoffs along the way. Do NOT expect you will get every feature you thought would be in your MVP into your MVP. That is ok! You’re editing at this point, and I think it’s forcing you to be very careful about what to include and what not to include. There are going to be non-negotiables, and that is great! They better support the top 10% of innovation.
Trying to solve everything upfront
You better plan to be wrong! Do not get caught up in edge cases. Put in engineered constraints.
Thinking that your engineering team can just “plug things in”
Certain things can be ‘plugged in,’ but there is always something that needs to be built to write up an integration. A great example is a customer that wanted a fully functioning analytics dashboard early. In reality, it probably would be best to build simple charts with the information at hand rather than spend thousands of dollars on an embedded analytics product. The problem is this embedded analytics product, while powerful, still requires implementation. There is a reason that companies like these require a service contract to be included in their sales — it takes work to integrate and stand up. This doesn’t make it less expensive to set up — it does make it easier to support new features in the long run, but is that necessary for the MVP? Probably not.
Losing touch with your design partners
This is quite easy to do — you’ve had dozens of discovery conversations and are ready to start building — so you aren’t talking to your design partners regularly and are just building. Having a regular cadence of showing where you are and getting rapid feedback from your potential users is a gift — while time-consuming, this activity can ensure you are continuing to solve the users’ problems directly. This role is often best played by your defacto or formal Product Manager and/or Product Marketing lead.
Conclusion
Focus and resilience are key to a successful MVP build. Set that ego aside and validate assumptions. Assume you are wrong! If you’re getting only positive feedback, you risk building in a bubble. Constructive criticism of your idea and product capabilities is essential to building a product that people want to use and solves a problem they want to be solved!
The Engineered Innovation Group is an innovation agency based in Indianapolis, IN. We help organizations create new and valuable products and services. We offer custom software development, MVP development, innovation consulting, and fractional CTO services.
We believe innovation shouldn’t be left up to chance. Engineered Innovation™ is deliberate practice, employing both divergent and convergent methodologies. Contact us today for a free consultation.
