A year ago, my team and I started building an incubator for gadget startups, in which we develop products from idea to mass production. We focus on creating gadgets that solve a known problem in a new way.
In this article I want to share my experience and tell you how we are trying to organize the development process in order to move as quickly and in the right direction as possible. I will talk about the process using the example of a product that will be shipped to the first customers very soon - Veer earplugs with adjustable sound insulation level for those who are tired of constant noise.
During the year we have filled a decent number of buds and have made some progress. One product was brought to the launch of mass production ( getsilence.com ), the second to the finalization of the construct ( tribrush.co ), the third to a strong-willed decision to postpone ( easymusic.club ), and about 15 potential products were also killed at various stages. Now, in parallel with production, we are developing several concepts for new products.
How it all starts: finding an idea
We have a whole search process, you can write a separate article about this, but some ideas are born almost by accident. For example, the Veer project appeared when we realized that our office is always very noisy - people are discussing something, walking back and forth, milling, sawing, working with a compressor, etc. It is difficult to focus on intellectual activity in such conditions, so many of the crew started wearing earplugs. Here new problems arose: when you need to exchange a few words with a colleague, and this happens often, you have to take out your earplugs and then put them back in. The process is a little annoying.
So the idea came up to make earplugs with adjustable volume. We found a couple of similar projects on Kickstarter, but none of them have reached the sale yet. Given the fact that crowdfunding often ends at the idea stage, we decided to give it a try.
Determine if it's worth taking on a project at all
We have a number of filters to help determine whether to take a product into development. The first is competencies. We do not take into development products for which our team lacks competencies ( or competencies are difficult to access) . The second is technological complexity. We have a subjective scale of ten, where 1 is a shovel and 10 is cold fusion. It is super-subjective and serves rather to synchronize perception. As a rule, we do not undertake projects with a complexity of 5 or more.
Veer on our scale is 3. Here, for example, are projects that we rejected due to their high complexity:
- . : , . , , 6. , , .
- . : , , , . , – , 5. .
In addition to assessing the necessary competencies and complexity, before starting the development, our marketers determine the target audience, potential market demand, look at competitors, the presence and awareness of the problem in the audience, etc., but this is a topic for another article.
Design principles
We often do things that are difficult to plan, so we adhere to two basic principles:
- The developer must do the most important task at any given time (this is not about tyranny, but about priorities).
- Work should be organized in reasonably short iterations.
The most important task is usually the one that provides the main user characteristic and / or identifies the main risk, depending on the detail and stage of development. To determine the most important task, each stage has its own artifacts, they will be discussed below.
For example, at the start of development, we had two important requirements for earplugs:
- It is necessary to provide the ability to adjust the volume of penetrating sound;
- The minimum noise damping level is no more than 5 dB (so that a normal conversation can be heard), the maximum noise damping level is from 40 dB (so that our earplugs are no worse than the best foam ones in terms of efficiency).
It was these tasks that we closed in the first prototypes, and only then we thought about the remaining tasks / risks - how to fit into the cost and size, can we provide a good user experience ...
Process artifacts: what is it all built on?
In order to somehow predict and structure the development process, we use four documents.
Document 1: task description
In it, the product manager describes the following points:
- What kind of product we do;
- Who are our users;
- What are their problems;
- Why do they need our product;
- When and how the product will be used;
- What properties the product should have;
- What are the competitors, how are they good and bad;
- Which properties are critical and which ones can be neglected.
After studying this description, the complexity of the project and the competencies necessary for its implementation are assessed. Further, the description can be adjusted to fit our limitations.
We use it to assess risks, think over a concept, etc.
Document 2: work plan
As a rule, this is a Gantt chart, which answers the questions of what should be done at all, in what order to do it, what influences what, approximately when the project can be completed.
At the development stage, such a plan is not some kind of document with clear tasks and deadlines, but rather an abstraction that helps to get a general idea of what awaits us. The planning process itself is more important here, when we structure the idea of the project, tasks, risks ...
For production, we make a separate Gantt - there the plan becomes critically important: on its basis, we agree on certain dates with the buyers. Here we are trying to take into account realistic risks and re-mortgage, although we still cannot take into account all the risks. For example, for earplugs, we ordered earpads from Chinese partners. We agreed on everything, wrote down the dates of shipment, counted the rest of the stages from these dates and announced a pre-order.
Clickable:
Two weeks later, the Chinese returned with the words: "This will not work, let's do it differently." They did not suit us in a “different way”, we had to look for an alternative for a week, pay twice as much for it - as a result, the shipment time increased dramatically.
Document 3: Development Backlog
This is a prioritized list of tasks from which we form weekly iterations. We try to formulate the tasks in such a way that their description would answer the question "What important property will the product receive if we do this task?"
The backlog is especially relevant at the development stage, when we need to clearly understand what and why we are doing. The basis for prioritizing tasks is user needs: the more critical a product property is for a client, the more critical it is for us. Earplugs are a very telling example because their key characteristics are obvious.
The priorities here are based on quantitative, qualitative research and common sense: volume control, then sound thresholds, then comfort, and so on.
We divide tasks in the backlog into ones that require research and others. For example, "Anodize the body of the earplugs with black" - here you can use a well-known technology, no research is needed to solve the problem. But " Provide noise reduction of 5-40 dB" - research. The ear cushions greatly constrict the ear canal, so we had to come up with a special design and test several approaches to achieve a lower noise reduction threshold of 5 dB.
Paper 4: List of Hypotheses
These are the experiments that need to be carried out to solve each research problem, arranged in priority order.
With such a list, we work according to a HADI-like pattern, we make the list in much the same way:
- Throwing in all possible hypotheses;
- We estimate the complexity of checking each of them (separately for testing and production);
- We evaluate our "belief in the success" of the hypothesis: how likely it is that it will solve the problem in our constraints;
- We calculate the total scoring score using the formula: time to test a hypothesis * complexity * probability.
This scoring score determines the priority of the hypothesis. Based on the results of the tests, the most important one, if the problem is not solved, we move on to the next one.
Instead of a conclusion
At each stage of development, there are a huge number of risks associated with the interdependence of system elements, and in production - with the manufacturability of the product, contractors, etc. Every time a risk occurs, we take it into account in the plan to understand where the bottleneck is now »And how the finish date changes. We did not find a balance between the approaches “ let's multiply all the deadlines by 10, then we will fit exactly ” and “ we will finish in 27.5 days ”, so we always try to do the most important things in short iterations. So, it seems to us that we react to risks faster, which means that in general we move faster.
We will be glad if our experience is useful. Write if you are interested in learning more about something. You can read more about earplugs on the official website of the project, here you can pre-order with a discount: getsilence.com
Subscribe to our channel , here we talk about the pain and suffering of the hardware production of Veer earplugs.