There are numerous ways to launch a product, but learning how to use agile methodologies to launch products is by far the best way to increase your chances of success while eliminating waste.
I know, that does not sound like a very glamorous or sexy way to get your dream business going, but trust me, in the long run you will be thankful.
Why? Because you will focus on the key things that matter at exactly the right time. And you will move faster and more efficiently. Sounds good, right?
What is agile? An introduction
Before we dive into the how, let’s have a quick look at what agile exactly is. It’s basically a set of principles — a manifest, if you like. It is designed to help you organize and manage your startup project for minimum effort, maximum learning, and more importantly, continuous improvement.
It sounds very much like lean startup. And that’s the idea. Agile, used originally in software development, allows you to be energetic enough, so that you can work in continuous deployment cycles. In this cycles you can learn what works and what doesn’t. Then you can make the subsequent improvements and move on to the next cycle.
Depending on the type of project you’re working on, you can use the variation (framework) of agile development that is the most helpful for you. In the world of B2B SaaS products, we at Starttech for example tend to use Scrum as our basic agile development variation. This is because it fits our needs as far as development, operations and pre-sales or after-sales support.
You have your MVP, so now what?
So with agile in mind, you have your MVP (minimum viable product) ready. It’s perfectly simple and ready to be tested out in the “wild”. But for some reason you feel that it is not ready. It needs more fine-tuning before you release it to whatever market you are targeting.
And that’s your first mistake. Sometimes startups loop around iterations of product development and don’t make significant process beyond a few “cosmetic” improvements. Launches are delayed and delayed until everything is “ready”. Really, your focus should be firmly on what you can’t do.
To launch or not to launch
But what does “ready” even mean? To what extent should features, back-end functionality, user interface and any other aspects of the product, be completely developed before your product is ready to hit the market? Are minor details that important? These questions might seem quite rhetorical but it’s not a philosophical matter.
One thing is sure. You should start with a few basic features and make sure they’re fully functional. More often than not, your customers need a simple solution, one that makes it easier for them to start using your product or service. And besides, you’re only trying to second guess what’s important for them. So use agile and go lean or go home!
How to use agile methodologies to launch products: your “checklist”
Analyse your situation
What’s the situation? Why are you delaying your launch. Are you doing repetitive development cycles without any feedback? Do you keep changing your strategy? When you’re about to complete a version of your product, does that accomplishment end up leaving you just at where you were in the beginning?
Investigate delays
Investigate what is causing your delays? Usually the most common things behind delays in finalizing and launching an MVP are these:
- Stubbornness: when you’re stuck on your own original idea and you’re not flexible in terms of adapting/changing it
- Perfectionism: when you’re trying to add more and more features to make it “perfect”
- Emotional reasons: Sentimental issues have killed many a startup ideas – or at least stopped them from pivoting. Is psychology the problem? Products are made by humans (for now at least), and when we get closer to “the release date” usually the development team gets stressed out and this leads to stalemate and caution to delay it “just for another cycle”.
Check if you are doing any of the above and then put agile into effect by being open to changing your ways and going ahead to test and learn. Or as it’s put in lean startup, build-measure-learn.
Why launching early on is really important
The main benefit of using agile to launch is that you will get feedback from customers. Or early adopters, whatever you want to call them. Because, and this is an important truth to sink in, nothing is static. Your market and your customers may also change or shift slightly.
These days everything moves at a fast pace. Technology itself changes quicker than we can often keep up, and of course there are other entrepreneurs that may be working on the same ideas that you do. They might have their MVP already ready and take it to market when you’re just chasing your tail. One more thing: the more you delay your product launch the more you face the reality of ruining your future chances. For example, you may run out of money, and you may not have the opportunity to launch at all.
Don’t listen to the “critics”; Use agile methodologies
Some people will tell you that if you go and launch your product when it’s not “ready”, you will risk more than your business, but also your reputation. First of all, when you’re starting out you’re just testing the water. Your product won’t be on everyone’s lips right from the release date (unless you have spent millions of a TV ad of course – not bloody likely). You’ll probably get unnoticed by your potential customers. It’s really tough to become visible. Save that for the inbound marketing a little later.
Critics of agile – who mostly don’t use agile methodologies – say that you’re just throwing your product against a brick wall to see if it sticks or breaks. But as Steve Blank says, this is not the case. Critics are going to be everywhere. Blank’s response to the above notion is this: ”Build a product, get it into the real world, measure customers’ reactions and behaviors, learn from this, and use what you’ve learned to build something better. Repeat, learning whether to iterate, pivot or restart until you have something that customers love.”
Your product is not static. And if it’s an SaaS product, it certainly should never be static. The road of improvement is long, and you need to utilize those early adopters in it to make the quick improvements early on. The result will be a more polished product when you try to cast your net wider.
Pick and mix
Just like when you were a kid and went to the pick and mix to fill up your bag full of candy, you didn’t take EVERYTHING. In working out how to use agile methodologies to launch products, it’s very similar. You can use the parts of it that make sense for you and your team. For example, estimating a task too much before you start working on it can be painful. So don’t do it! If you’re spending a lot of time and energy estimating things, without that task actually adding any value to your project in the end, then stop doing it.
Also, in product road-map planning, trying to hold the team accountable to it may prove tough. But it will be better than using exhaustive planning and estimation exercises. This doesn’t mean you’re not agile. Agile can be difficult, because it’s always different. As a general rule, if you are doing it more than once the exact same way, then you are doing it wrong. Your goal should be that everyone is on the same page, working on the right thing, in the right order and at the right time. Therein lies the real value.
Epilogue
In working out how to use agile methodologies to launch products, the above advice is a great starting point as you look to make your way with your product. Agile can be a great ally, if you use it correctly for your specific needs. Your first port of call is to understand what you are doing wrong, and why you are doing it. From there, agile can provide answers to many other more important questions you will have about your product and its development.
One final thought. According to agile methodology, projects are built around motivated individuals, who should be trusted. But sometimes it takes a little more than that. Of course people need to be trusted – and your startup needs a culture of trust to be successful – but they may also need a little help, in order to use agile methodologies. Don’t we all?
