Validating your idea prior to handing it off to a software house

Software development

One of the most common mistakes when creating a startup is not having an accurate idea for a product. If you intend to succeed you have to know exactly where your project starts and where it will end. Changes to your project are imminent and expected. However, before you throw your idea over the fence to software developer land, make sure all the requirements are explicitly specified and not too much room for interpretation is left.

If you don’t know how to do it, please be my guest for the rest of this article.
As Eris Rise states in his book “Lean Startup” (I will refer to this valuable book in this article): Startup success is not a consequence of good genes or being in the right place at the right time. Startup success can be engineered by following the right process, which means it can be learned, which means it can be taught.

Here’s the first trap that can put the success of your project at risk right off the gate.

The conflict between business and technology

Very often, projects struggle due to a very profound issue – misunderstanding between the customer and the development team. Developers and business folks are two completely different types of stakeholders with different perspective and understanding of the project. They think and operate differently on a day-to-day basis, and it would be illogical to expect them to switch their brains to the other way of thinking and excel at it. Thus it is important to understand that fact and be aware of their differences in approaching projects, problems, and solutions.

How to remedy this potential issue?

At Astra Software we recommend that our customers (and potential customers) follow two simple rules in the initial idea pitch:

1. Narrow down room for interpretation of your idea

2. Be flexible regarding technical implementation of your idea

The goal of those two rules is to have maximum clarity of your business case – separate the most important functionalities (a.k.a user requirements) and define why you need them. Also, specify why they are important for you and your project. Remember also to set a clear budget and time expectations. It is important for the technical expert team to factor in those limitations t. I’ll get back to time constraints further in this article. As for the technical implementation details – the HOW side of things – we recommend leaving it to the experts so they can leverage the technology and fully spread their wings.

In the next step, you need to answer the following question:

What is the most important feature or aspect of your project?

Despite dozens of books out there deliberating on successful startups, many business owners are still guilty of making the same mistake. It is common that they want to have everything at once, even if not all of the requirements are essential at the moment. This approach not only increases the cost but also delays the project delivery time and as a result skyrockets the risk of failure. It also negatively impacts both the customer and the developers. We don’t recommend trying to tackle everything in one milestone especially if you are thinking about testing your idea in the marketplace first and then developing it further.

With our customers, we recommend a different approach. In the first delivery, we create an MVP (Minimum Viable Product), which is nothing else than just creating the most basic version of the product that resolves the issue.

Validating Software Idea MVP

Building an MVP is a familiar element of a Lean Startup process. In a few words, Lean allows testing your idea with minimum resource engagement. It’s important to know that MVP will confirm business assumptions whether a project is important to the average user. Don’t be discouraged by your product’s minimalistic design, if it solves an important issue for your customers, they will use it, and they will be very forgiving. In “Lean Startup,” Eric Rise writes:

“The goal of a startup is to figure out the right thing to build – the thing customers want and will pay for – as quickly as possible.”

In many cases, if a solution to a problem is in demand, a simple landing page will be a great beginning to collect information and feedback from prospective customers.

Based on Noah Kagan‘s experience, potential clients will overlook many imperfections in your software if it resolves a valid problem. Moreover, sometimes, just pointing out the problem is already a great beginning.

It’s important to pay attention to accurately identifying a problem as Jim Semick points out on ProductPlan’s blog:

Start small

In his fantastic book “Zero to one“, Peter Theil recommends that even the companies who intend to become the only solution provider to an existing problem should start small. Would Facebook become such a huge success if they began on the global market instead of just one Harvard University? Such tremendous success would have been much harder to achieve then.

Make sure you aim to solve an issue that is important. In another example in ‘Zero to one,’ Peter Theil describes the early days of PayPal when their team focused on a very narrow technology which didn’t bring any significant results. However adjusting their product to eBay sellers solved a real problem for a considerable number of users.

When you define the problem.

Planning – finding common language with the software house

Passing information to your Software House is a critical factor for your project’s success. At a glance, it sounds like a natural activity that involves meeting for a coffee (see our other article on how to pick the right software house in Canada). More often than not, it is one of the hardest of all phases because it involves validating the requirements with the expectations.

Questions you should ask and answer before you complete this phase:

1. What do you care about? Are you thinking of testing your idea or do you know exactly what the average user needs?

2. What is the purpose of the MVP?

3. What functionalities (user stories) are necessary for the product to do its job? Assign priorities such as high, medium, low to help you be more objective during your decision process.

4. What is your budget?

5. Should you move to the next phase and start the development?

Case study

One of our customers, during a meeting, explained that the product has to reach a certain number of users to be successful. A quick math exercise resulted in a formula and a report showing that the product would have to essentially double the user base on a month-to-month basis for the next few months to achieve the expected result. It’s not impossible, but none of the requirements supported such aggressive growth. As a consequence of this conversation, we came up with different features as well as activities that would support a feature that was of such importance to the customer. We also prioritized the requirements accordingly and revisited the budget for this project. Had we not had this conversation, I’m sure the customer would not be happy with the result of our work even though the development team would do what the customer wanted on the dot. I think it is both parties responsibility to ensure that the project is well defined and that both requirements and expectations are in sync. It was the best moment to change the course of the project without incurring extra costs, not mentioning the frustration.

Unfortunately, many software houses or freelancing companies won’t go the extra mile to understand the what the customer needs. Hiding behind a list of requirements or a signed document only shows a communication breakdown and never ends well. That is why I can’t stress enough how important the initialization phase is to the project’s success.

Validating software idea

An excellent software house will help you clarify your idea. At Astra Software we always start with a research of your real needs also known as requirements elicitation. Clients often have ideas about what features they would like in a product and what these features should look like.

Many customers, however, have limited knowledge of how software is built and vague ideas regarding what makes a project successful. It can be difficult than for clients to understand what they truly require in a product. It is the role of the software product manager to help the customer figure out what they “want” and what they “need.”. This practice is a fundamental part of successful project delivery.

Real needs and problems should surface during project initialization conversation. Pat Flynn mentions that in his book “Will it fly” that is dedicated entirely to the process of business idea validation. When he was working on his niche website about food trucks, he sincerely talked to the owners of such businesses. He didn’t ask direct questions, though. Instead, of asking what their biggest issues were, he steered the conversation in the right direction and just listened to what the business owners had to say. More often than not, the customers aren’t 100% sure what it is that could improve their business or solve their problem best.

We implemented a similar process, based on communication with customers. We focus on their needs, we research and recommend best solutions all that to finalize the project with customer satisfaction.

Summary – how to best clarify your idea?

First of all, focus on the problem you are trying to solve. Next, think about the dent your product could make in the marketplace. Moreover, we recommend using proven working models and processes presented in “Zero to One” or “Lean Startup” and also practiced in our company. If you are considering working with us, we will be more than happy to hear from you!

Share This