in   Software Development   Prototyping   Software   Hardware

Phase 1. Research. Software & hardware development process

Imagine having a friend who one day comes and says that "I choose to go to the Moon in this decade (...)". Crazy right?

We all have those amazing ideas. Ideas that keep us awake at night. Ideas that could be game-changers. Which one, however, has a chance to change something on the market and gain users?

I invite you to the next article in the series about our software and hardware development process. This time I will describe in detail what is important in Phase 1. Research. If you haven't read the first article in the series yet, I recommend starting with it to grab the context of our rapid prototyping approach:

We choose to go to an MVP. 7 phases of the software and hardware development process inspired by NASA

All engines running. Fasten your seatbelts and liftoff!

nasa-n463SoeSiVY-unsplash

Photo by NASA on Unsplash

Table of contents

Have an idea? Try to be its greatest critic and ask yourself a few questions

What does the Phase 1. Research consist of?

Wrap up

Have an idea? Try to be its greatest critic and ask yourself a few questions

Before starting a heavy product development journey, we have to start the process by convincing ourselves that there is an opportunity or try to criticize our own idea.

Answering a couple of simple questions might help:

  • What is the problem that I want to solve? Is this problem just mine? Who has this problem?
  • Are there any better ways to do it? Has anyone tried it already?
  • What do others think about my idea? Especially those who have such a problem?
  • Can my solution be implemented? How?
  • Why do I want to build something?

The idea behind our Phase 1. Research is to answer all of those questions the best we can. And try to "build the specs" from both technical and business (customer requirements) side. We do that by scratching our heads, brainstorming and exploring all the options. Don’t get me wrong. It’s still a fast and iterative process (isn’t it rapid prototyping?), but according to my experience, it is worth to do research responsibly, because it is cheaper than engineering.

What does the Phase 1. Research consist of?

Start with why and define the problem

We start work by defining the problem we want to solve.

  • What is driving us, why do we want to help specific people?
  • Who will use it?
  • How and when people will use it?

Most often, the beginning of the FemTech project that we work with looks similar. The founder had a health-related problem and couldn't find a solution on the market, so she decided to create it to help other women with similar issues. If you have a problem that you want to solve, you need to know how many others you can help, i.e. how big your target group can be.

If you don't have this problem, you need to find relevant people to deepen your knowledge and try to understand them. The key to success is the user-centric approach from the very beginning, and empathy will help you with this.

Ask for everything that comes to your mind.

  • Where does this problem come from?
  • Can it be divided into stages?

Perhaps someone from your test group will have an idea of how to solve it. Don't assume anything, doubt, try to make a couple of theses, and refute them. Rely on data, not opinions.

Invite experts to cooperate, look for data, and market research on this topic. Don’t speed up this phase unnecessarily, because if you do not do it well enough later you can overlook a lot and lose. On the other hand, we remain faithful to iterations and frequent verifications of theses in the software or hardware prototyping process.

Check the competition. Perhaps such a product already exists on the market.

  • How does it help people?
  • How big is the interest?

If you are able to do something better - you can go on, but if the problem is at the heart of the idea - it's worth considering whether it is reasonable to develop it further.

Out of the shadows. How will the product work?

If you already know that you are able to give new value to the market, you can find for your product or service customers, you need to deepen the topic of the product itself.

It’s the most flexible phase of the whole product & software development because it depends on the case. You need a lot of brainstorming to gather all the ideas and possibilities. You should generate as many questions as possible and try to find answers for all of them.

  • What is the biggest value of this solution?
  • What basic functions should it have, and what will be nice-to-have?
  • How will we reach interested customers?

If on the way we are not able to answer any question, or in the meantime we find that the idea is not worth further development, then it's more than okay. We will save time and therefore money. You simply can devote energy to another idea.

Decision point. Plan what to test further

Perhaps the research will give us alternative options, and we can now make a pivot. That’s fine and it often happens in the product or hardware development process.

If the idea seems right and worth developing, we should still think about business constraints.

  • How are we going to earn and when?
  • How do we want to fund this idea?

At this stage, we already have to plan what we want to test further (whether it is hardware or software).

  • What further theses do we want to confirm or refute?
  • What will be the priorities?

Further down the line, we will split more into two distinct paths, as Tyler Mincey from Bolt likes to call them, it’s the “looks-like” path and the “works-like” path.

The “looks-like" path is based on:

  • discovering the right customer requirements (customer segments),
  • creating prototypes, wireframes and ‘fake it till you make it’ renders or models (we check if our presumptions are correct),
  • making sure all the presumptions and specifications are correct.

The "works like "path is based on:

  • finding out how the product engineering side looks like,
  • proving, and demonstrating functionalities and building specs.

Now we can proceed to the second stage of the process, Phase 2. Proof of Concept.

Wrap up

We start with an idea, but the execution is the most important thing. At least until we test, we won't know if the concept is worth anything.

As originators, we often succumb to the temptation to trust our idea and implement it too quickly. An engineer who prefers to build and test may have the same approach. However, it is not worth skipping the research phase, because it can answer many important questions for further development. It's also definitely cheaper than prototyping.

What to keep in mind during Phase 1. Research of software & hardware development process?

1. Define the problem:

  • What is driving us, why do we want to help specific people?
  • Who will use it?
  • How and when people will use it?
  • Where does this problem come from?
  • Can it be divided into stages?
  • How does it help people?
  • How big is the interest?
  • What is the biggest value of this solution?
  • What basic functions should it have, and what will be nice-to-have?
  • How will we reach interested customers?

2. How will the product work:

  • What is the biggest value of this solution?
  • What basic functions should it have, and what will be nice-to-have?
  • How will we reach interested customers?

3. Plan what to test further:

  • How are we going to earn and when?
  • How do we want to fund this idea?
  • What further theses do we want to confirm or refute?
  • What will be the priorities?

Thanks for reading this.

This was the second article in the series of Untitled Kingdom’s software & hardware development process:

1. We choose to go to an MVP. 7 phases of the software and hardware development process inspired by NASA

Next time we'll look at Phase 2. Proof of concept.

If you have any questions or feedback, just let me know.

 
Bartek Hugo Trzciński

By

Head of Technology by day and software engineer by night. Recently solving more problems in business and mangement than in code - hard to tell which one is more fun. Local dev groups activist. Automotive enthusiast. Boosted Board shredding champ. The best companion to dance and to give you a ride.