How our startup incubator built a process for Veer earplugs development from initial idea to production
Hello everyone, I am Andrew.
A year ago we started a startup-gadgets incubator where we develop products from an initial idea to production. Our concept is to invent gadgets that solve old problems in a new way.
In this article, I am going to share our experience and open up about the way we accelerate the development process and ensure its proper direction. As an example, I am using our recent product that will soon be shipped to our first customers — Veer earplugs with volume control, designed for people who are tired of constant ambient noise.
Over the year we have had some ups and downs but we still achieved progress. One product has been brought to launching serial production (getsilence.com), another one is at the stage of concept finalizing (tribrush.co), and third has been deferred until the right moment (easymusic.club). We have also worked through and refused 15 other potential products. Now, along with production, we are developing concepts for several new products.
How it all starts: The Idea Search
We have a complete process for searching for ideas. It would take a whole new article to describe it in detail, but some ideas are born almost accidentally. For instance, the Veer project was launched when we realized that our office is too noisy: people areconstantly discussing something, walking around, milling, sawing, working with a compressor, etc. Focusing on intellectual activity becomes challenging in such conditions, so some team members started wearing earplugs. This led to new challenges: when you needed to talk to a colleague, which often happens, you have to take earplugs out and, when the conversation is finished — put them back.
So we arrived at the idea of making earplugs with a volume control. We found some similar projects on Kickstarter, but none of them had made it through to actual sales. Assuming that crowdfunded projects often end at the “idea” stage, we decided to try and start our own.
Evaluation of the project’s prospects and whether it is worth investing our resources
We have several filters that help us to decide whether we should start development or let it go. The first is our expertise. We do not start projects where we lack experience and expertise (or the expertise is hard to acquire). The second is technical complexity.
We have an arbitrary 10-point scale where 1 — for a shovel and 10 for cold fusion. The scale is super-discretionary and serves us for the synchronization of our perception. Veer takes 3 points according to our scale.
As a comparison here are two projects we rejected:
● A dog’s paws cleaner for owners of medium and large breed dogs. When you come home after a walk, you just put your dog’s paws into the device to clean and dry them. The existing products do not wholly solve this problem, and we drew our concept. But its development complexity was estimated as 6 out of 10. It is more complex than we expected, so we rejected the idea.
● An automated cat’s litter box. The story is similar: we wanted to make a robotic litter box without litter, which cleans itself right after a cat finishes the toilet. It was supposed to collect the waste into a leak-proof container and roll it out ofthe box leaving no smell, no waste — a good concept, but the estimated complexity was a minimum of 5 points. So we gave up on this idea too.
But the evaluation of necessary expertise and complexity estimation is not enough. Before starting the development our marketing team determines the target audience, test potential market fit, and look for competing products, validate the problem existence and awareness, etc. — a topic for another article.
Development principles
We often do things that are difficult to forecast, so we adhere to two basic principles:
- At any point in time, the engineering team must solve the most important task (which is not about tyranny, but about prioritization).
- Work must be organized in rationally short iterations.
Normally, the most important task is the one that ensures salient product features and/or defines the main risk — depending on the current particularisation and stage of the development. To determine the most crucial task at each step we have our own artifacts, which I describe below.
For example, at the start of the earplugs development we imposed two main requirements on the product:
- We must provide the ability to control the noise cancellation;
- Minimal level of noise cancellation must be up to 5 dB (so a user can hear normal conversation), the maximum level of noise cancellation must be from 40 dB (so the performance of our earplugs will be as good as the performance of foam plugs).
These very features we were aimed to be fulfilled when making the first prototypes, and only after that did we think of the rest of the tasks and risks: for instance, how to fit in prime cost, the required size, and how to ensure a good user experience.
Process artifacts: what is everything built on?
To predict and frame the process we use four documents.
Document 1: task description
In this document our product manager describes the following points:
● What product is to be developed?
● What is this product’s target audience (TA)?
● What problems does the TA face?
● Why does the TA need our product?
● How and when will the TA use the product?
● What features will the product have?
● What are the other competitors, and what are their strong and weak points?
● What product features are salient and which one can be disregarded?
After getting acquainted with the description the engineering team evaluates the project complexity and availability of the required expertise. Then the description can be amended to comply with the limitations.
The description is also used when we evaluate risks, elaborate on the concept, etc.
Document 2: Workplan
It is usually a Gantt chart that answers the questions of what we should do; in what order should we do it; what tasks are at risk of delaying the project and what won’t affect the project timescale; and roughly when the project is expected to finish.
At this development stage, such a plan is not a document or something determining tasks and deadlines precisely but is more of an abstract, which helps us to get a clearer idea of what to expect. And what is more important — it is a planning process: when we frame perception of the project, tasks, and risks…
For the production stage, we make another Gantt chart, where the plan is critically important: based on it we agree on product release dates with customers. And at this stage, we strive to consider realistic risks and to be overcautious, though it’s still impossible to forecast all the risks.
For instance, we found Chinese partners and ordered production of ear tips for our earplugs. We agreed on the time frame, set out shipment dates, and based on these dates we calculated the other stages’ durations and announced preorders.
In two weeks the partners returned to us saying: «We can’t do it this way, let’s try another option». But we were not satisfied with the option, so we had to spend another week looking for an alternative, which cost us twice as much and drastically extended our deadlines.
Document 3: development backlog
It is a priority-based list of tasks, which we use to plan our one-week iterations. We strive to formulate tasks’ descriptions in a way that allows us to answer the question: «which attribute will the product get if we attain this objective?».
The backlog is especially valuable at the development stage when we need to clearly understand: what do we do and in what order. The basic principle for objective prioritization is customers’ needs: the more critically a customer needs this attribute, the more important it is for us to implement. The veer project is an emblematic case because this product’s salient attributes are obvious.
In this case, prioritization is based on qualitative and quantitative research and common sense: noise cancellation control, then noise volume threshold limits, then wearability comfort, and so on.
We divide the backlog tasks into those requiring research and other tasks. For example, a task «Anodize earplug’s aluminum body black» implies using a broadly-known technology, so does not require further research to complete it. While a task «Ensure noise cancellation within the range of 5 to 40 dB» does require some research. Ear tips narrow the auditory canal considerably, so to ensure the lower level of noise cancellation to be at 5 dB, we had to devise a special construction and test it several times.
Document 4: List of assumptions
It lists experiments that we need to conduct to solve prioritized research tasks.
We work with the list using HADI-like pattern, drawing a list almost the same way:
- Generate all possible assumptions.
- Estimate the complexity of validation of each assumption (separately for testing and production).
- Evaluate our “belief in success” of assumption: how likely is it to solve the task taking into account our limitations?
- Calculate overall score using the formula: time spent on assumption validation*complexity*likelihood
This score helps us to prioritize assumptions. Based on the most important task test results, we get onto the next one — if the task is not solved.
Some closing remarks
At each development stage, there are a great number of risks, related to the interdependence of system elements, and there are additional risks at the production stage: related to product manufacturability, contractors, etc. Every time, that a risk arises, we take it into account in the plan to understand where the «bottleneck» is now and how the deadline is affected. We have not found a balance between approaches «let’s multiply deadlines by 10 and we won’t be delayed for sure» and «we will surely finish it in 27.5 days» — that’s why we try to do the most important tasks in short iterations. This, we believe, helps us to respond faster to any newrisks and to accelerate the processes.
We will be happy if our experience can help anybody. Please comment if you want more details. You can read about our earplugs and place a preorder on the project’s official webpage: getsilence.com
