Unexpected Lessons from V1 Product Launches
The lessons I least expected from startup product launches
Growing up I was fascinated by the genesis stories of now huge companies like Apple, HP and Microsoft.
I loved how these companies were capable of designing, building and shipping computer products while being in garages.
As an engineer I’ve been fortunate enough to be part of product launches in startups and quite often most valuable lessons taken from the experiences were the ones I least expected.
I don’t always believe in boiler-plate guides, or sets of rules for projects that by nature vary in how they can be executed.
What I have found useful however is learning about the experiences of people who have been involved in product launches themselves.
Valuable lessons for me qualify as advice I would give to myself and the team I was part of at the beginning of each project I was involved in.
The following article will go over lessons learned during product launches that I did not see coming and would find valuable if I was going through the process again.
Bigger is not Always Better
When I was at a 5 person team, our product launch was part of a crowdfunded pre-order campaign.
Our team had people responsible for product design, electronics, firmware app development and logistics, and we won a grant to work with a large consultancy.
We decided to use the consultancy as their client-base included large, well-known companies and we thought that their experience would help us improve our products physical 3D design, ensuring it would be ready for manufacturing.
The unexpected lesson for us was that the work delivered by the bigger consultancy was well suited to bigger clients.
Some scenarios that were less suited to smaller companies such as startups included the following.
Corporate Catchups
Every week we had an hour-long catch-up which was a roundup of previous weeks work we already knew.
In our faster paced culture of work we were less inclined to spend an hour of our day (3-person hours if 3 of us were in the meeting) learning what we already knew.
We understood (without generalising) that this is more common in corporate working environments.
Alpha Prototypes
As we approached the final week of their product delivery from them, the final design was referred to as an “alpha prototype”.
Calling the design that we had already spent two years on, that we planned to go to market with, felt really odd and symbolised the misalignment in timelines we had in mind.
Despite us being clear with what we intended to do with their deliverable, they clarified that the first deliverable they produce for all clients is considered an alpha prototype.
Timeline Misalignment
Calling the deliverable an alpha prototype was more than a name and represented what was discussed in the final meeting.
We requested design files the day before the final delivery presentation, that there were several mistakes with the dimensions.
We were told that best practice for all clients they have is to have an extensive testing period for designs they produce, which for us was 2-3 months before going to market in 6-9 months.
As a startup with tight deadlines we needed to go to market in 2 months.
Lessons Learned
We learned the value of smaller consultancies and individual freelancers who understood our deadline requirements and working processes.
Working with larger consultancies was still a positive experience, and is one I would still recommend if the opportunity came so long as the following are managed:
Ensure full clarity on deadlines
Be part of setting the agenda for meetings so key info is presented
Still take on board their best-practice suggestions while running them by others in your network so you learn the most about larger-scale project management
Christmas Delivery Danger
Many hardware startups launch products on crowdfunding platforms such as Kickstarter, as they work on the basis of people pledging support for products they want to see in the market, which they can receive in return for their pledge.
The pledging system works similarly to pre-orders, where a set goal for total amount of money pledged is chosen, and if it is fulfilled then the product is made and delivered to customers.
Most often the set delivery date for the product is several months after the campaign closes, however quite often deliveries are delayed and in some other cases are not fulfilled at all.
For many startups the preparations for online product launches in general involve considerable marketing investment with a lot at stake.
Some founders, particularly selling consumer products for children may be tempted to set a delivery or hard-launch date for Christmas, to incentivise the support of their product as a gift for friends and family.
Although it is understandable to ensure that product launches have the highest chance of commercial success, launching at Christmas on platforms like Kickstarter adds additional pressure to launch on time.
Like many Kickstarter campaigns, if yours is delayed further after Christmas, you risk your relationship with some of your earliest supporters.
It is worth adding that in the event it does happen, many people who regularly buy products from platforms like Kickstarter understand how common it is for deliveries to be delayed and will not hold anything against you.
Lessons Learned
If you want to go for a special launch that can increase chances of people wanting to buy your product over the festive period, ensure that the project planning takes time for setbacks into account.
Hardware development cycles will often be delayed and putting pressure on technical teams to deliver for such a high-profile holiday can lead to more issues than needed.
It is also worth considering other weeks, holidays and events that you can plan a launch campaign around that still fit the theme of your product.
In my experience, having the whole team be part of the decision for when we deliver our product and how we plan for it ensured everyone’s voices were heard and taken into consideration.
Start Working on Compliance Early
When releasing a product to market it has to comply by regulatory standards.
Navigating the legal domain of regulatory compliance can be daunting for many small teams whose skills are geared towards technical, commercial or scientific product development.
The stakes are (rightly) high to release a safe product to market.
The process typically involves:
Identifying the countries your product will be solid in
Assessing the intended use
Identifying what standards your product needs to comply by
Carrying out tests to obtain certification
When planning product development cycle, it can be easy to think of planning for regulatory compliance as one of the final stages of releasing a product.
Leaving the planning to the final stages exposes you to the following risks.
Medical Approval Requirements
There are some products (such as electro-muscular stimulation ab-stimulators that require FDA approval even if their intended use is not medical.
Acquiring FDA approval is an expensive and time-consuming process, however a less obvious risk is that some crowdfunding platforms no-longer allow products that require FDA approval to raise money on their platform.
These crowdfunding platforms tend to be those which work on a pre-order basis (money is pledged in exchange for the product, as opposed to shares in their company), and have taken this stance as so many products fail to get FDA approval and subsequently cannot fulfil their orders.
Addressing compliance early gives clearer indicators early on for:
Costs
Timelines
Platforms to launch from
Team profile
Design Changes
Some compliance tests require their laptop to physically connect to your device, while your device is running a dedicated test mode software.
For anyone with a hardware background reading this, an example includes running the device in dedicated radio frequency (RF) mode, and connecting to it over a serial interface such as UART.
It is important to check early-on if your device’s design can facilitate physical connection it may require for testing and if you have access to the dedicated test mode software.
If your device does fail any of the tests, design changes may be required to pass the following attempt, and as hardware design changes require manufacturing, redesigns will delay the process.
Lessons Learned
It is important early in the product development process to anticipate the consequences of failing compliance tests and managing risks by considering pre-compliance testing for a stronger understanding of how likely passing or failing is.
If you are not experienced in compliance testing, it is worthwhile to:
Setup calls and meetings with test-houses early to see what advice they give around standards to test to
Reach out to people who can provide advice and support on navigating compliance such as freelancers, or Unit 3 Compliance, based in the UK, are a test that provide advice and support to startups
Understanding the the big picture of what regulatory compliance preparations you need to make de-risks many unexpected circumstances down the line, and allows you know what support you need.
More People = More Delays
One of my earliest experiences in a startup as an electronics engineer involved wrestling with an illusive bug that prevented our first prototype getting tested.
Pressure was on to solve it and we brought in a freelance engineer for a few days to help us debug further.
The freelance engineer was much more experienced than me and was really helpful in teaching me key principles. We used their expertise to run tests on our product, and despite them being very helpful we eventually found the cause of the problem, which we fixed a few weeks after they left.
After we fixed that bug, to our surprise we came across another unrelated one immediately after, which turned out to be due to a change we made in the software as part of our tests with the freelancer.
At the time, we were able to debug the subsequent issue, and get the products out for testing.
A very experienced colleague of mine at the time told me I should read “The Mythical Man Month” to learn more about why we came across this issue.
“The Mythical Man Month” is a book published in 1975 by Frederick Brooks, which comprises several essays based on his experience working at IBM on a project called OS/360.
Brooks observed that when a project was running late, adding additional team members to it delayed it further - a concept known as known as Brooks’ Law.
The mechanisms causing delays outlined in the book include:
The time taken for new engineers to learn about the project
More people means more interfaces and channels of communication
In my earlier example, the freelance engineer introduced a software change that the rest of our team who are remote did not see.
Although it was no ones fault, more channels of communication increased the risk that a software change made in unusual circumstances was left in the codebase by accident.
I strongly recommend people in engineering and management read “The Mythical Man Month”, additional ideas are also presented in book and they are all insightful.
Lessons Learned
Bringing additional help into a project can be useful particularly when there is a lot of pressure to solve a specific problem.
Managing new people coming into a team, whether permanent or temporary basis requires sufficient onboarding, which can be challenging if in a startup environment they are in the team for short amount of time.
What’s important to remember is:
Bringing people into a team should not a knee-jerk reaction to delays, communicate with those involved with technical development to see if they want additional people on the project
If bringing someone in is the consensus decision (like in our case) ensure all changes to work, even those seemingly low-impact are well documented and shared amongst everyone in the team