So you just released version 1.0 of your software app. Congratulations!
For those familiar with software, you already know this is just the beginning, not the end. And if you’re doing software right, you still have a long way to go.
That’s because version 1.0 is not your “full” product. In fact, it’s not even close yet to the software you envisioned. And that’s good, because you don’t want to build anything just because you envisioned it. You want to build commercial software because it delivers what people actually want — and are willing to pay for.
Version 1.0 of your software should be what we call a Minimum Viable Product (MVP).
What is a Minimum Viable Product?
An MVP is the smallest version of your software that delivers real value to customers. This must be the value they would be willing to pay for, whether you’re charging for it at that point or not. The premise of an MVP is to get your product to market quickly – and to isolate what creates value for your customers.
For information on MVP, we discuss it in much more detail in our article about when to bring your mobile app to market. For a simple definition of the concept, you can also check out this entry from Techopedia and this video by Eric Ries.
Why Should Your MVP Be Version 1.0?
The sooner you start getting real feedback from real customers, the sooner you start shifting from what you planned toward building what customers really want. This is especially true when those real customers are also paying customers because now they have at least a small investment in your success.
Once you’ve identified your MVP, it makes sense that it would be your version 1.0. Why?
- Anything less than your MVP is not a viable product and shouldn’t be released.
- Anything more than your MVP and you’re spending time and resources on what you think your software should be instead of what the market tells you.
Common Complaints with Version 1.0
Most of us know that almost every software version will be subject to some complaints. Version 1.0 is no different. In fact, version 1.0 is often the most criticized of all. That’s because you’re providing basic functionality, not a slick, full-featured application. There are no fancy interfaces, bells or whistles. The good news, however, is this: all the complaints and feedback you receive will help you formulate an even better version 2.0.
With this in mind, here are some of the most common complaints you’ll be exposed to:
- “It doesn’t do everything I want.”
- “I found a bug.”
Bugs are unacceptable at any level, of course. Even the smallest MVP should receive rigorous testing before launching into production. A good Scrum-based development process will achieve this.
But bugs in software are a fact of life. Some always sneak through the most rigorous testing processes. But if you build it right, there should only be a handful, not a deluge.
The remaining “complaint” – and I strongly urge you to consider it feedback at this point – helps you identify those features your customers want most.
Manage Expectations by Managing Your Audience
So let’s say you take your MVP, launch it as version 1.0, and publicize it to the global media as a full-fledged product. Do you see how that’s just asking for trouble? And you’ll get it, too!
A better solution is to control your audience. Invite a few of your ideal customers to try your software version 1.0. Their feedback should be the most valuable to you, anyway. Communicate that this is just the beginning – that you want their help to grow your software in ways that will help them, too. That way they get a lot of influence in the development of the product — without having to invest in building the software themselves. You could easily call that a win-win.
These kinds of invites also serve to give those initial customers incentives to provide good feedback. Plus, if you target your best customers, they’ll be more willing to work closely with you, anyway. You can even treat them as partners if you want. Strengthen those partnerships – and the quality of feedback – by giving them insight into your production backlog and how you’re prioritizing those tasks.
With each new production launch, you decide if – and how far – you want to widen the net. Are you ready to ramp up yet? Will the software support it? Is an appropriate customer support team in place?
Remember that each time your audience expands, you gain new perspectives and feedback. So you’ll want to scale it up quickly — if you can do so without sacrificing quality.
Scaling Up Your Software – One Sprint at a Time
So how do you transition from a skeletal version 1.0 to that full-featured commercial software you planned to market to the world? How do you get from your MVP to that slick, boxed version flying off the shelves of the local Best Buy?
One production sprint at a time.
You see, when you develop with Scrum, each production sprint focuses not on some long-term plan, but on what’s needed now. With each sprint, you’ll re-prioritize your outstanding features (called a product backlog) and select those that can provide the most value in the next two to four weeks.
This is how you handle the “complaints” we mentioned earlier. But you’ll need to prioritize them with all the other tasks and feedback.
Bugs should be addressed as early as possible, typically in the next sprint. Keep in mind that a true Scrum production sprint will include thorough testing and the product should be as close to bug-free as possible at all times.
New feature requests can be addressed through the sprint process. If and when those features become top priorities on your product backlog based on the type of customer feedback you’re receiving, that is. Anything less, and it should be apparent by now that you have more important things to do.
So this is how you’ll ramp up from tens to hundreds to tens of thousands of users. First, prioritize the feature requests. Then let your engineers figure out how to build them. And, finally, fit those new features into your sprints when the time – and your need – is right.
