MVPs - LESSONS FROM THE FRONTLINE

Startups and enterprise companies have one key goal in common - they want to build successful MVPs. More precisely, they want a killer app, with unicorn potential. However, startups typically lack sufficient capital to get close to their dream and enterprise clients often don’t have enough of the right talent. Startups have started to embrace more cost effective “low code” development platforms; enterprise clients outsource to agencies, acquire companies for their talent (acquihire) or recruit new dev talent for the job. However, whether you are a startup or enterprise, many other factors affect your MVP’s prospects. Below are some issues that I have encountered whilst working with startups and enterprise clients, expressed as lessons learned.

Lesson #1 - Change Your Mind

First, the seemingly obvious, but typically the first stumbling block - your minimum viable product (MVP) is not just a “small product” or “low quality” version of your product. Simply put, it should be functional and reliable, with features that allow you to prove or disprove your hypothesis about the customer’s problem(s). However, it only needs to have limited functionality (use the 80/20 rule) and delight your customers by solving their problem(s).

Second, your MVP is a learning tool. It need not be an end product itself. Specifically, your MVP does not need to be a great product. You can always build a great product, but not before you have proved your hypothesis to be correct. For example, most clients I’ve worked with finally opted for Web Apps instead of Native Apps, but only after accepting the true purpose of their MVPs. To put this into context, in one case, we were able to validate an idea by using google ads and a landing page. Continuously identify your most risky assumptions and test them. Minimize development time and effort - include only the capabilities required to discover whether you can solve your customer problem(s). Just build something that will enable you to learn and get useful customer feedback. The MVP mindset is key.

Lesson #2 - Be Inspired

Most Unicorns did not launch with fully fledged products. Many started by attacking a single problem and some started with no product. See below.

Zappos - founder photographed shoes at local shops and uploaded them to a website. He only purchased and shipped shoes after people actually bought them. Very low initial costs and simple to get started.

Dropbox - founder released a three-minute video that demonstrated synchronization with Dropbox. It drove hundreds of thousands of people to the website. Low cost validation before getting started.

Airbnb - founders placed an ad about renting an air bed on a simple web page. No location maps, no payment gateway. Once they had bookings they redesigned their website. Simple start and low cost.

Buffer - Founder tested whether people would use software to schedule their tweets by using a two-page website. There was no product yet. Once proven, the website appeared. Simple solution and low cost.

Groupon - Founder tested the product idea by using email and PDFs to propose local group deals and offers. Only after it was successful did they create their platform and expand geographically. Simplicity rules

Remain inspired.

Lesson #3 - Don’t Believe the Hype

Your business requirements should determine the most appropriate tech stack for your MVP, not the other way round. Agencies are inevitably biased in favor of tech stacks for which they have ready skills. Some have standing armies of developers with skills that your MVP may or may not benefit from. Agencies need to utilize their resources and I have seen how Agency Bias gradually takes hold, sometimes resulting in bloated MVPs that resemble polished end products. In-house teams may also be similarly endowed with skills that may or may not be the right fit for your MVP. Match your business needs - time constraints, key requirements and budget - to the most appropriate tech stack.

After many years supporting clients to select the right agency, I am no longer surprised by the very significant differences in both time and cost estimates for equally skilled and competent teams (with seemingly similar quality output, brand equity and cost bases). In some cases, even estimates from the same company (obtained at different times or via different channels) are sometimes wildly different for the same or similar work. Understandably, at the end of most sales quarters, department heads and sales teams become infinitely more optimistic and flexible. Also, different teams and resources will have different work capacities, depending on their skills and experience. Therefore, to get close to more reliable estimates I always compare estimates from at least 3 tier one and 3 tier two agencies. Then, before work starts, I work with the development team - the people who will actually do the work - to get more realistic time estimates. Always listen to those who do the work.

Lesson #4 - Embrace Simplicity

Maximize the amount of work not done and radically minimize both development and deployment complexity. I have seen clients deliver Progressive Web App (PWA) MVPs with the same capabilities as Native Apps, but in half the time. Web Apps offer a simpler alternative to more complex Native apps.

Also, Native App deployments require app store approval. From personal experience, this requires both time and effort, including changes to comply with the app store’s evolving requirements. Web Apps offer full deployment control.

Your MVP should also minimize complexity for users. Native apps add more steps and considerations to the customer journey - the app must be found and downloaded from an app store brimming with apps that could be seen as alternatives to your newly approved Native App. Whilst PWAs can also be found in app stores, they are also available directly to users via a single click on a web link. Web based apps are more easily and widely accessible to significantly more users - they do not discriminate, or block users based on which mobile platform they use. Always choose simplicity over complexity.

Lesson #5 - Explore the Territory

Your MVP will take you into uncharted territory. There may be no maps, yet. You will be guided by customer feedback and the results of your tests. Your role is to formulate a hypothesis, identify what to measure and get the data you need to prove or disprove it by ruthlessly testing your assumptions. You have to explore multiple options and perform numerous experiments to start to understand how to explore your new territory.

After months building a web app based on a business model that required a minimum customer conversion rate, one client tested multiple landing pages and form combinations. Those experiments finally gave us the green light to continue on our MVP journey. However, we would have been equally grateful for an early signal that invalidated the hypothesis or prompted us to continue experimenting. Draw your own maps, to explore and conquer your new territory, by probing and testing.

Lesson #6 - Stay Legal

If your MVP is affected by internal and/or external regulatory and compliance requirements you must identify and employ appropriate specialist talent to work closely with your development team. Internal requirements may include those imposed by your company’s corporate governance and enterprise risk models or those of your partners. External requirements are those that your MVP must comply with due to legal and/or regulatory frameworks affecting your MVP, imposed by governments in one or more jurisdictions.

On another project, the client misunderstood the regulatory framework that governed their partners’ operations and after building and successfully testing the MVP, they had to make major adjustments to legal agreements and the way their MVP operated. Ideally, embed specialists in your MVP team and proactively research requirements and devise the most appropriate response to identify compliance requirements. Build compliance into the MVP to make sure that requirements are addressed prior to each release. External requirements must of course be complied with explicitly. Carefully review internal requirements and where possible accommodate the needs of your MVP whilst always remaining compliant. Adopt automation (this is also relevant for documentation) to drive testing and reporting. Take the right action early to remain compliant.

Lesson #7 - Engineer Success

Many organizations now use agile frameworks for product development but not all do so successfully. Adopt the practices below to support and improve the pace of your MVP development. See below.

Pursue team stability - MVP development is a learning process and a stable team makes this journey more efficient and effective

Measure performance - Use average velocity (based on the last few sprints)

Be realistic - Accurately calculate the team’s potential workload and never overburden them. Your team will be more likely to finish early and accelerate faster

Implement buffers - Be realistic and include a buffer for things that might interrupt the team’s progress

Fix it now - Make sure that code fixes are implemented asap. Going back to fix or clean code takes significantly longer than fixing it immediately.

Make it flow - Avoid bottlenecks and make sure that the work flows by getting 2 or more team members to work on the same priority item(s) until done.

Improve it - At the end of every sprint cycle, identify one improvement to be implemented during the next cycle.

Measure happiness - Monitor team happiness and be well positioned to address problems before they arise

Document plans B to E - Agree a procedure to address a failing sprint. For example, reprioritize, get more resource, swarm, escalate or replan the sprint.

Implement the above and watch your MVP team’s performance improve.

Lesson #8 - Observe, Orient, Decide and Act

First, identify the right metrics, avoiding those that simply make performance look good but do not help you understand it in a way that informs future strategies. The wrong metrics will make it appear that your MVP is moving in the right direction but they often aren’t actionable and aren’t related to things that you can control or repeat in a meaningful way. Actionable metrics help you make the right decisions about the future of your MVP and specifically how well your MVP is solving the problem(s) that it was developed to solve.

Next, make sure that you implement and ideally automate a measurement and reporting system to enable you to easily gather and act on the results of your MVP experiment. Share feedback and decisions quickly and transparently. Continuously review metrics, make decisions and take appropriate action to find the best way to address the customer problem(s). Observe, orient, decide, act and repeat until you prove or disprove your hypothesis.

Lesson #9 - Get started and…

Examine the target market and alternative solutions. Listen to target customers and estimate the value of the product to them. If you sense an opportunity worth going after, develop your MVP and continuously identify and test risky assumptions. Remember, your MVP does not need to be a perfect product.

Carefully estimate the effort required to solve customers’ problems and continuously prioritize based on what customers actually do. Manage your stakeholders, gather feedback and aim to build a customer centric product that addresses real customer problems.

Continuously question whether you have a market opportunity with customers who are willing to use and/or pay for your product; explore usage and get early feedback and insights to guide your next move.

Just do it and be sure to use market feedback to know when to pivot or persevere.