How do you eat an elephant?
One bite at a time, of course.
This old, cheesy joke actually has some truth to it. Just as the “one step at a time” mentality can (and should) be applied to many things in life, it also applies in business.
At RTS Labs, we encourage starting small for many projects. Starting small doesn’t mean thinking small. There’s nothing wrong with having big plans. But, trying to take it all on and make all your plans happen at once could end in wasting time and money – or worse, failure.
While starting small isn’t always the best practice, in these three examples, starting small and lean can lead to increased success and decreased waste. Here’s how starting small leads to winning big – the lean startup method way!
Why Startups Should Start Small
The lean startup model is popular for a reason. Its core tenant is to start small with a minimum viable product (MVP). We liken building your MVP to building a small ship. You build a small ship, make sure it floats, and then you keep building and adding to it. Your MVP is your starting off point. It’s what you use to pitch investors, attract beta users, and learn about your customers.
If you shoot for the moon and try to build your whole product at once, you could end up overbuilding and wasting valuable time and resources on a product that ends up failing. You’ve got to make sure your foundation product works first. By staying agile and iterative in your process, you can more easily pivot and change course if need be.
For more on MVPs, check out, “4 Steps to Building a Successful MVP.”
Why Technology Projects Should Start Small
Much like a startup, if you’re ready to tackle a new technology project, you need to start small. It’s easy to get caught up in features and lose track of scope, purpose, and resources. Start by clearly defining the problem you are solving and how it will be solved with technology. Then, do the research to determine how this new product is going to affect your workflows, processes, and employees.
Once you’ve answered those questions, strip the project down to its most essential parts. And, just like a startup would, build an MVP – a small ship that you will test to make sure it floats.
Stripping down the project will allow you to focus on the features that are most important so you don’t go crazy trying to focus on too many features at once. It forces you to prioritize, so you build, test, iterate, and repeat. Once you know your small ship is going to float, then you can work in sprints to continue building. As you build, you will begin to see which features are actually necessary and which are not.
Working this way keeps the focus on your core product and helps you think through features. As a result, you learn what works and what doesn’t. It also helps the development team find bugs easier and quicker.
We strongly believe that when it comes to estimates, starting small is the way to go. When new clients come to us, we encourage them to start small (in the way we’ve just described to you). In turn, we start small and take our time on each estimate for each project. When these two processes mirror each other, everyone wins.
At RTS Labs, we spend a lot of time on the discovery and scoping process for new clients. For example, if you were a new client, we would take the time to learn about your business, your business processes, and your unique pain points. Together, we would sit down and list every feature you could possibly want in your new product or app. From there, we would then strip the project down to its most basic function. This is where we start with estimates and scope.
When scoping projects, we set budgets, create timelines, and clearly define the scope of the project. We create specific milestones so we don’t get off track. When it’s all said and done, we present you with a plan – an accurate one with small steps and a solid timeline.
There’s a reason the lean startup method is so popular. By starting small, you save time and resources and end up with more accurate timelines and estimates. Want to know more about preventing your technology projects from failing? Check out, “The #1 Reason Why Technology Projects Fail.“