7 Tips to Minimize Thrash When Developing Your MVP (v2.0)

As the popular adage “the first step is always the hardest” suggests, developing a quality minimum viable product (MVP) is perhaps the most difficult part of your product development process. For one thing, you’re starting from “scratch,” that is with little more than what you and (hopefully) a few others think is a good idea and some data to support your thinking.

Moreover, if you are developing something that solves an important problem in the world, there probably aren’t too many good examples of what you’re trying to build. Add to this input from business partners, customers, investors, potential competitors, journalists, etc., and the process of developing an MVP can get out of hand very quickly.

Although it may not seem like it, every company experiences this “thrash” in the early stages of product development. Whether you are at a large company or a fledgling startup, companies go through (sometimes) hundreds of iterations on a product concept before “shipping” a single line of code.

Some companies even “scrap” products right before a highly publicized release. This thrash is a natural part of developing new products, but the key is to minimize the amount of thrash in your product development process.

Here are seven tips to help you do this:

1. Define specific and customer — centric business objectives for your product. This one may seem obvious, but a lot of teams don’t take the time to reflect on why they have decided to build something. For inexperienced teams in particular, product development tends to be driven by “gut” feeling instead of strategy / data. The obvious problem with this approach though is that teams will waste a lot of time defining and redefining their product. To avoid this waste, spend some time defining clear business objectives for your product and frame them in terms of your customers’ needs (e.g., To help a mid-sized organization increase its lead conversion rate by 30%). Your MVP feature s should subsequently focus on meeting these business objectives and nothing else.
2. Develop a general theory about your customers’ behavior. Defining customer — centric business objectives is not easy, and the prior requirement of identifying your customers’ most important business problems is even tougher. To help ease this process and improve the probability that your product will focus on the right issues, leverage mixed — method research. A great framework for doing this type of work is hypothesis testing, where you look at some observational data about customer behavior on existing products and possibly some macro level data on industry trends. Once you have this data and make some observations from it, develop some hypotheses to help explain those observations. Test these hypotheses with qualitative research and some small experiments and arrive at a general theory. This theory should frame your MVP definition process, and while it may not explain every nuance of your customers’ needs, it should address the broad strokes.
3. Get alignment early. As a corollary to number 1 and 2, having well — defined and customer — centric business objectives is useless unless you can get all of your stakeholders to align on them. Once you have your customer-focused goals defined, spend time to align with your product team, leadership and other internal stakeholders to make sure everyone is on the same page. At worst, you will make sure that everyone is aware of the direction that that team has chosen, and at best you’ll get some valuable feedback that can help you improve the product experience, avoid a potential risk and perhaps even change your direction entirely. To be clear though, getting alignment does not mean that everyone agrees on the product features; it simply means that everyone has had a chance to consider and discuss the relevant decisions that impact the MVP you will ultimately ship. In fact, products that everyone is happy about rarely ever succeed because the product has likely lost its differentiation somewhere along the road to agreement.
4. Realign as needed. It would be foolish to think the direction you align on first is the direction you are obligated to continue moving in. Rather, once you have initial alignment make sure you do one of two things depending on your delivery timeline. If your timeline is long (i.e., a few months) then make sure to conduct formal (e.g., inbound with customers, market analyses) and informal (e.g., weekly team meetings) to make sure your originally aligned direction is still valid. During each of these checks, you’ll end up in one of two states: 1) Your direction is valid → Keep Moving, 2) Your direction needs to change → Make a change. If you end up in state 2, that’s totally fine, just go back to numbers 1 and 2 above and realign your team. At the end of the day, product development is a fluid process and understanding how to handle the ebbs and flows is critical.
5. Set attainable deadlines and meet them. For many people, one of the toughest parts of shipping an MVP to market is fear of failure. This fear manifests in many different ways (e.g., adding one more feature, going overboard on QA, etc.) but the consequence is always the same — a thrashy and delayed release. In talking with several product developers, I learned that the ones who successfully released a product to the market imposed and met strict deadlines throughout their product development process. You have the next release to throw in that extra feature, so don’t waste time pushing back deadlines at the expense of getting feedback from the market sooner. As a tactic to meet your dates then, spend some time planning the key milestones for your MVP and then rigorously check to make sure you’re on track. If questions about pushing back timelines come up, really work hard to understand whether the pushing back the timeline is crucial for your to meet the business objectives you defined.
6. Move fast and realize you probably won’t get it right the first time. One of the biggest pressures that people face when developing an MVP is the pressure to get it right the first time. To be clear, this isn’t something that comes from external parties like investors, customers, etc., instead it is an intrinsic feeling caused by some emotion that falls between insecurity and the need to win. While forcing yourself to get it right may sound like common sense, there is a huge body of research (and anecdotal evidence) about how moving fast, failing fast and trying a bunch of things is ultimately a better strategy to attain success (e.g., Originals by Adam Grant). There are some caveats to this, specifically around mission critical products that need to be perfect from the start, but for the vast majority of audiences the “move fast” wisdom is probably right.
7. Document everything and treat it like a contract. An unfortunate (and wrongful) consequence of “Agile” development is that people assume nothing beyond a set of 3-line “user stories” is needed to develop a product. For successful product development though this view couldn’t be farther from the truth. Your developers need to understand what to build. Your QA team needs to understand what should have been built so that they can identify discrepancies in what is actually developed. Your product team needs to be comfortable that your QA team approved a product that functions as intended and your outbound marketing / sales team needs to know that they are pitching features and functionality that actually exist. Your requirements document is the “contract” that sits at the center of the relationship between all of the aforementioned stakeholders, and you should therefore treat it as such. Impose rigorous change control requirements and educate all parties involved about the importance of the requirements document. Without this type of control your product is likely to experience serious delays in its release.

Delivering an MVP with low “thrash” is not easy. It requires a combination of strategic rigor, flawless execution and spartan — like mental toughness; and even then it is difficult. But applying the tips above may help you get your product out the door faster, with less resources and in a way that sets a foundation for quick iteration as you move towards product — market fit.

This is version 2.0 of an article I published in 2014. You can read the original article at the following link: http://bit.ly/2dsi4hX