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. Additionally, if you’re developing something that solves an important problem, there probably aren’t too many concrete examples of what you’re trying to build. Add to this, “noise” from business partners, customers, investors, potential competitors, journalists, etc., the process of developing an MVP can very quickly get out of hand.
Although it may not seem like it, every company experiences this “thrash” in the early stages of product development. Whether it’s Facebook today or a small unknown startup developing it’s first concept, companies go through (sometimes) hundreds of iterations on a product concept before writing a single line of code. Some companies even scrap products after they are on their way to an alpha release.
This thrash is simply a natural part of developing new products. The key to success though is learning how to minimize the amount of thrash in your product development process.
Here are three tips to help you do this:
- Define specific and customer — centric business objectives for your product. This one may seem obvious, but a lot of entrepreneurs don’t take the time to reflect on why they have decided to build something. For inexperienced entrepreneurs in particular, product development tends to be driven by “gut” feeling instead of strategy / data. The problem with this approach though is that many young entrepreneurs don’t know what they don’t know and therefore waste a lot of time defining and redefining their product. To avoid wasted effort and resources, 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 set should subsequently focus on meeting these business objectives and nothing else.
- Set attainable deadlines and meet them. For many entrepreneurs, starting their own business often means not worrying about someone looking over their shoulder or telling them what to do on a daily basis. Unfortunately, this “be my own boss” paradigm often results in delayed product delivery timelines. In talking with several entrepreneurs I learned that the ones who successfully released a product to the market imposed and met strict deadlines throughout their product development process. Indeed, you’re always going to have the next release to throw in that extra feature, so don’t waste time pushing back deadlines at the expense of releasing something. As a tactic to meet your dates then, I recommend having someone outside of the product organization “policing” product development timelines.
- Treat your requirements document 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 business development / sales team needs to know that they are selling 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 stringent change control processes on your 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.
Defining, developing and delivering a MVP with low “thrash” is not easy, but using the tips above may help you get your product out the door with less wasted resources and more time for improvement.
If you liked this post, you can follow me on Twitter at @thezainpasha
Email me when Zain Pasha publishes or recommends stories