Over the years that we’ve worked on numerous projects, we’ve learned that building great software products is much more than writing the code. We see our role as the tech part of your team, working together towards the same business goals.
When building a new software product, it’s much more important to focus on the right features and act on customer feedback to find the problem/solution fit. Choosing the right features is not easy and the fact that less is more at that stage makes it even harder.
Before kick-starting the project with the development team, we help our customers plan the roadmap, choose the right technology stack, and define the right measurements.
How does the startup ecosystem work?
Why the startup way, you may ask? Startups disrupt markets by making decisions at the pace unreachable within traditional corporate structures. Enterprises can leverage “the startup way” when innovating. I’m pretty sure you are familiar with Lean startup. In case you’re not, let’s focus on the main elements:
Build → Measure → Learn
That’s basically how things work. It’s also quite a natural way of learning things. Think about a child learning how to walk. The child learns with every mistake made on the way. Let’s see what happens when I lean forward a little more… Oh, OK, I fall on my face. If that doesn’t work, let’s see what happens when I lean backward, just a little. Oops, floor again. Observing the results of each action, the child can then learn from these mistakes and finally learn to walk right. And then it can run.
The Build – Measure – Learn approach in creating a product is very similar. First, you create something, then you measure the outcome, then you learn. In today’s world, you can easily get quantitative information that will show you whether your product is working or not. With this knowledge, you learn what to do next. You can iterate over your idea to find a better way to get to your first goal. Or you’ve actually achieved something and are now ready to get to the next level.
The key here is to focus on the one thing that is most important for the end customer and measure her success. The first goal you set is not about launching the ready product. Creating enterprise-level software can be a project that can take up to a few years and millions of dollars for development. Let’s say we’re building a product and it’s estimated to take 3 years and cost 2 million dollars. The problem is that the end result is unknown. Throughout the 3 years, while the product is being developed, everything around is changing. So is the business. The software may not be useful anymore.
Instead of choosing to go big right away, you can set short goals with effects that can be measured and a budget that can be managed. Moreover, smaller parts of software already generate value. This means that you start to generate a return on your investment after a few months, not years.
How to validate an idea?
In order to begin a process of such kind, first, you need to find an idea. It can come from a problem that you see. It can also be an improvement in your internal processes, a new product for your customers. Even a new business model – like subscription for wine instead of selling the bottles.
The best way to document the goal for the first iteration is to focus on the basic value proposition of your product. Understanding the customer profile – their jobs, how they can profit from achieving their goals, and the pain points in the process – is the key to shape the product.The goal here is to find a group of the users excited with the new way of doing things and make a product that they’d call the best solution to that problem.
You want to show that your assumption in the value proposition really works.
When you’re starting with testing your assumption, you don’t need to have a huge budget and long-term development plan. What you want to do is get your prototype or proof of concept ready as fast as possible. Then you have your users use the software and give you valuable feedback. Note that the first step is NOT a minimum viable product. You don’t want to start making your app with an MVP.
The MVP proves the product/market fit, the moment when your customer acquisition data proves that you can dominate a certain niche. Before focusing on customer acquisition, you want to make sure that the users you acquire benefit from using your solution. If you promise your customer to save her time, you need to measure that you really did.
How to scale things that work?
Technology is only a way to scale things, Bill Gates says. You apply it to things that you benefit from – you will benefit at equipotential scale. If you apply it to the process you lose on… you will lose faster than ever.
Many companies start acquiring customers massively as soon as the features are built. If you do that you risk losing them if they don’t capture the value created easily. That’s why we advise our customers to put a lot of effort into customer success, learning how they approach the solution, looking for any friction. To do that and get the feedback, you will observe the sessions, interview customers, demo the product, and train them.
When you prove the product/market fit and you want to acquire users very fast, you can use these learnings to automate the onboarding, redesign the UX to the fastest way the customer can get what they want.
Automating these processes and measuring the Customer Acquisition Cost, the value generated, and the Customer Lifetime Value is what lets you get to the majority of your target group when you can really profit from the investment.
Only at that moment, when you have market data showing that you are the best solution, should you focus on increasing your market share, your revenues, build new features, and adapt your software for other use cases.
Although in the examples given we focus on building a new product for your customers, the tactics used to apply for your internal solutions as well.
The Build → Measure → Learn approach helps you mitigate the risk of assigning a big budget to a project that you’re not certain will succeed. It helps you build something that is really needed and valued by the customers. Additionally, you develop the product in a structured way so that you can start one initiative after another.
Your questions answered = your problems solved
The software you create is only worth the change its impact brings to your business. When you plan to launch a software development project, you make a lot of assumptions on how it will impact you. Building the right hypothesis and making sure you scale only what works for you and your users is the path to success.
Betting millions of dollars on an uncertain outcome that can be verified years from now… This is how the majority of IT projects fail.