Who This Is For
- If your internal R&D resources and specific skills are limited and balancing product support with R&D needs is difficult.
- If you know there has to be a shorter and easier way to bring products to market than what you have seen so far.
- If you are tired of projects constantly exceeding time and budget limits, and still not meeting business objectives.
- If you are tired of juggling multiple vendors and partners to deliver reliably.
- If you are worried about managing multiple stakeholders and their disparate priorities.
- If you suspect you are building the wrong product for the wrong niche to solve the wrong problem due to a lack of the right skills and processes.
- If you suspect there has been a huge investment and years of effort only to discover a few key faulty assumptions were made and wish it could have been discovered sooner.
- If you hate wasting engineering bandwidth on failed projects and demotivating key people.
- If you are worried about keeping the most important decision-makers interested and convincing them to fund the next round of financing, then this is for you.
You can take an IoT Proof of Concept to an Alpha product in 3 months.
However, most companies are not equipped with the skills and internal resources to do this since the technologies used are relatively new and the process requires deep collaboration between business, technology, and product development people.
We are the best people dedicated to solving this particular problem for engineering managers and CTOs. This is why Krakul exists.
We are the only company that combines world-class business, technology, and product development expertise to solve this problem for and with micro-mobility companies.
Background Story / How we discovered this
Krakul was founded in 2013 by a couple of engineers from Estonia’s most successful space project called ESTCube-1. The founders had a background of competing in engineering and robotics championships and finding creative answers to tough problems in short time frames.
To achieve success in these domains that have difficult constraints and a low margin for error, one needs a deep understanding of the business goals, and a lot of technical know-how coupled with an iterative approach to the process. At the same time, those domains teach you to thread the needle between thriving in ambiguity and achieving a precise outcome.
This holistic perspective helps keep the focus on the result and to come up with novel solutions to whole systems and subsystems that could not be achieved with overly specialized approaches that are more suited to mass production. Coming up with a creative and effective solution takes a different skill set compared to executing a known solution.
Only a few people have a background in IoT technology, and have successfully launched products and manufactured them at scale. The people that do, have a lot of insights that can help others.
The founders began helping other companies with design and development and found that their skills and approaches honed in the space industry and engineering competitions helped their customers achieve success much faster and with less risk.
This led to others asking the founders what they did and how they did it.
Eventually, the company grew into an international IoT and autonomous systems consultancy that has helped more than 90 customers. Here are some of the lessons we have learned.
How to do it
To bring your Proof of Concept to the Alpha product stage in 90 days, there are three key areas to consider: Business, Technology, and Process.
Step 1: Review, define and validate the business requirements
Review and validate the Product Vision and the Business Requirements
- Old way: Decisions about the business and technical needs are made prematurely. The POC is part of a top-driven initiative with multiple assumptions that are not validated or reviewed by all stakeholders. The initial plan is highly detailed on what the product has to do and how it is supposed to do it. Those assumptions are then copy-pasted onto the Alpha product phase.
- Old result: The POC will work technically, but will be hard to operationalize and not fit the context. The wrong product will be developed for the wrong market.
- New way: All assumptions of the POC are uncovered and reviewed at a deeper level from multiple perspectives. The business reasoning and the “why” is understood by all participants. Everyone understands how the product will impact the business internally and externally and how it will fit in the company’s portfolio and strategy.
- New result: There is certainty and clarity in the way the product:
- Will be used
- Will be manufactured
- Make money
What can I do right now?
Consider the following questions:
- How validated are the business assumptions of the POC? Make sure what needs to be achieved can be done within the planned budget and timeline. If the reasoning behind the business goals is unclear, you are going to run into problems.
Example: The focus is solely on meeting price and technology targets without validating the use case and the business model.
- Consider all stakeholders and their business models. IoT offers opportunities for new types of productized services that could bring in new revenue.
Example: preventive and predictive maintenance contracts as a source of revenue for service providers. A maker of smart lamps can offer their data to installers that can now offer lighting as a service to customers. Use Alex Osterwalder’s business model canvas and Steve Blank’s Startup Owners Manual as a starting point.
- What are there unvalidated gaps in the assumptions?
Example: A pool supplies company decides to gather pool chemistry data over wifi. It turns out that this complexity could have been avoided by using electronic SIM cards and connecting over a telecommunications network.
- Are there any unconsidered stakeholders, such as logisticians and operations people? Example: There is an initiative to tag all items in the warehouse with an RFID tag. Everything can now be tracked, but the whole process is hard to operationalize and provides no business value.
- How will you analyze the data?
- How will you create value? Are you selling the device, service on top of the device, or the data? The data that IoT devices collect can be of interest to local governments or other organizations. For example:
- The fleet of Beryl Bikes generates passenger transportation data that can be used by local governments when making infrastructure investment decisions.
- Audi now manufactures cars, that have the same capabilities, that can be activated by software.
- Peloton provides a device, but a lot of the value can be enjoyed over the paid software on top of the device.
Optimise the Value Chain
- Old way: Make a plan for the sourcing of the components as their availability is reasonably fixed.
- Old result: If nothing changes and the supply chain stays as it is, you will be fine. In today’s world of de-globalization and supply chain disruptions, this will lead to unmanaged risks.
- New way: Make a comprehensive overview of the whole value chain and leave room for changes and dynamic substitution.
- New result: It is impossible to de-risk the supply chain, but it is possible to shift the risks to areas, where the risks can be mostly managed.
What can I do right now?
- Make a price and availability assessment across the value chain for
- Supply chain / Component sourcing assessment.
- Make sure to form and maintain great relationships with the leading component suppliers such as u-blox, Richardson RFPD, and others. Without it, all the sourcing plans are just plans.
- Consider the locations of individual steps in the supply chain. For example, if the assembly is not done in Brazil, but the product will be sold there, you will face a 70% import tax. Does it make sense to ship all the components to a single location, pay for storage, and constant availability of assembly engineers? What if you could outsource certain parts of the value chain to areas that are closest to the customer? In one case we helped a customer dramatically decrease fixed costs for manufacturing, shipping, and inventory as well as reducing their lead time by helping them get rid of central in-house manufacturing.
- Component availability
- Cost and complexity of scaling: The total cost is made up of two parts: NRE (Non-Recurring Engineering) and COGs (Cost of Goods). The only way to reduce COGs is to invest in the NRE. There is a trade-off between NRE and COGs. With quantities of up to 1000 pieces, it is impractical to reduce the price of COGs if the targeted unit cost will be less than 10k USD. Typically the NRE cost is between 5%-20% for 100k units annually / cost typically 10-20MUSD. In this case, it will make more sense to stick with off-the-shelf components.
- For example, if you are designing devices with low power requirements, optimizing for unit costs, or optimizing for production efficiency, you will be looking at significant investments in NRE.
- A typical formula considers the following: Product lifetime value = Amount of potential customers x target price/unit cost of the device x costs/benefits of various features.
Validate the roadmap
- Old way: Everyone follows the plan that was initially proposed. Deviation from the plan is discouraged.
- Old result: There are constant miscommunications, delays, and impediments that always come as a surprise. This leads to missed opportunities, fingerpointing, and exceeded budgets and timelines, which in turn will lead to failed projects.
- New way: The roadmap is continuously validated with all stakeholders in marketing, sales, development, production, and delivery.
- New result: The product can continuously be improved with stakeholder feedback and react to changing requirements.
What can I do right now?
Collaboratively create, disseminate and continuously review the timeline for:
Form a plan and review it constantly with all parties to give time for marketing and sales to ramp up. Make sure the decision power does not solely rest in the hands of marketing and sales as it runs the risk of forever adding new features and never getting released.
Step 2: Process
Choose the right project management approach
- Old way: The assumption is that the better we plan, the better we can anticipate the future. Reducing deviation from the plan is always a good idea. Optimize for cost and use multiple vendors based on their hourly rates. Use a big upfront plan, and couple it with a heavy project management methodology and a detailed change management procedure.
- Old result: The delays between team members cumulate and lead to long delays. A lot of the communication is lost or misunderstood between team members and between the different disciplines. The complexity of interdisciplinarity in IoT is underestimated. Projects often fail to meet their targets in scope, budget and time.
- New way: In a context of high uncertainty, reducing the cost of change is always a good idea. Change is anticipated. Teams are cross-functional and co-located to reduce miscommunication and delays. Assumptions are uncovered early.
- New result: Projects end on time and within budget or the infeasibility of expectations is discovered before major investments are made.
What can I do right now?
Form Agile cross-functional co-located teams. Make sure mechanical-, electronics, and software engineers are co-located and have access to users and the business leadership. New product development demands cooperation from multiple stakeholders and disciplines to be successful. Heavyweight project management approaches (e.g. Six Sigma) that strive to reduce deviation from the plan are more suited to environments with less uncertainty and ambiguity such as manufacturing.
The interdisciplinary technical complexity of IoT can best be solved by colocated engineers who can collaboratively detect and solve problems on the spot.
Use short iterative cycles and fast feedback
- Old way: Plan the work and work the plan. All assumptions remain valid until the end of the project when we integrate and test. Mid-project end-user testing is seen as an unnecessary cost. Even if the teams are co-located and cross-functional, constant communication about progress and unvalidated assumptions does not occur sufficiently to make a difference as it reduces perceived valuable engineering time.
- Old result: Assumptions are uncovered too late in the project when there is very little one can do.
- New way: The cost of testing and validating is seen as a way of reducing risk. Team members are constantly in contact with the business leaders and end-users.
- New result: Blockers and show-stoppers are discovered before it is too late.
What can I do right now?
- Make sure the three technology cycles sync. A hardware product iteration cycle takes 3 months. An electronics and mechanics iteration takes a month and the software part takes two weeks.
- As more development is done, new information about the feasibility, desirability, and viability of the future product is uncovered. Expect and prepare for weekly changes to occur in the business requirements. Keep asking what and why questions to find out the true need. Then give options with price tags to the business decision-makers to keep the process moving. “The client does not know what they want and they keep changing their mind” is the natural state of things at this stage.
- Consider the nature and trend of the news. Is this a blocking problem and do we need to make fundamental changes? Do we pause or proceed? Example: we have chosen a case that blocks radio frequencies, but now we would like to learn what is going on inside it.
- Test with all stakeholders, including the end-users, as early as possible.
- Hire people with a can-do attitude who thrive in ambiguity, and are good at communication and execution.
Step 3: Technology
Keep requirements and design options flexible for as long as possible
- Old way: Point-based design. Decide at the beginning of the project which technologies to use, and optimize for unit cost and efficiency prematurely
- Old result: You are forced to say no in places, where you really would like to say yes because you made certain decisions too early. It’s an all-or-nothing bet.
- New way: Set-based design. Define the outcome, but not how to get there. Decide what are the last responsible moments for making certain critical decisions. Design with modularity in mind and use a high level of abstraction. Leave room to make more decisions later as new information comes in.
- New result: The product will not get stuck by the limits of a specific technology when product requirements change.
What can I do right now?
- Keep requirements and design options flexible for as long as possible. Example: When designing a battery pack, it might be best from the safety and price standpoints to include the simplest processor. It later turns out it would add a lot of value if the battery pack could be remotely accessed and managed. Leaving this option open might seem like a large cost, but the option to have that decision later is worth it. Premature unit cost optimization will lead to higher costs and risks. As a rule of thumb, it is always good to leave flexibility for software capability. On the other hand, if you go too far, then an overly capable processor will eat away all the battery power.
- Find the right balance between off-the-shelf and custom components. What is the planned quantity? Would it make more sense to use off-the-shelf product kits or use custom-designed components?
- As a rule of thumb:
- Up to 1000: use as much off the shelf components as possible. (Exception: specialized military gear)
- 1000-10 000: balance off the shelf and custom components.
- 10 000+: using custom components will be cheaper in the end. For planned 10k devices, every 100k EUR invested in NRE will result in 10 EUR added cost.
- Communication and localization infrastructure. How will the device communicate?
- External: no connectivity, cellular, Bluetooth, WiFi?
- Internal: CAN, Ethernet, industrial protocols, etc
- Do you need to act in or just sense the environment? Actuators and sensors (temperature, humidity, noise).
- Power requirements: wall or battery-powered (primary or rechargeable)?
Integrate and test early and often. Ensure architectural integration and testing with end-users and stakeholders
- Old way: Everyone follows their individual targets and plans and strives for (local) optimization.
- Old result: Integration is a separate stage at the end of the project. It will always exceed planned targets and often fail.
- New way: Co-located cross-functional teams. Continuous integration is part of every stage of the process.
- New result: Problems and risks are discovered early enough to make course corrections.
What can I do right now?
- Make sure the product is architecturally sound and that the different layers work well together.
- Refer back to the business vision and requirements. Is the product meeting expectations? If not, adjust accordingly.
- User testing: For example does the device need to communicate to the user that it is now connected over Bluetooth? How will the user expect to be notified? Should it flash a blue led light or vibrate? The product needs to adapt to people’s habits and expectations, not try to retrain them. Testing in life-like conditions as soon as possible helps validate those assumptions.
- Cross-functional testing. Whatever is done, needs to be tested with other functions as soon as possible. Testing is a cost, but at this stage of the process it pays off really well. Removing bugs and wrong assumptions at later stages of the process will be many times more expensive.
As you can see, all you need to do is to modify the way you approach business, technology, and process aspects and you can take a POC to an Alpha product in three months.
Option 1: Use your existing team
Firstly, you could look to do this yourself with existing resources. But as we’ve discussed:
- Alternative costs. The engineers you are now diverting were working on something else that will now be neglected.
- Inertia and bias. The existing team will use the tools and methods that are available to them. These might not be the best for the POC to Alpha context. They will be pigeonholed to do things the way you have always done.
- There is a demand and plan for the existing engineers. They can be called away despite your best efforts to help them focus on a new initiative. Today’s products need support and therefore slight delays will creep in the best of plans. This results in a week’s delay here and two weeks there, leading to many months of wasted time.
- They do not have the necessary relationships with the right suppliers to minimize supply and manufacturing risks that will come up at later stages of the product lifecycle.
Option 2: Build a new team
Secondly, you could seek to build a new team. The issue with this approach is that:
- It takes a long time to form a team: attracting, selecting, and hiring. The problem with good people is that they already have jobs and need to be convinced to join your organization. By the time it is achieved, the market opportunity might have passed you by. They might have excellent specialized or compartmentalized skills in individual domains of either electronics, software, or mechanics, but might not have the needed tolerance for ambiguity and constant communication that is needed for this stage of the product lifecycle.
- Interpersonal chemistry. A great team is much more than the sum of its parts. Getting the people from all domains to work well together can take years of effort. There is no guarantee that a recently formed team will perform well. Even if you succeed in hiring individual superstars, it does not guarantee that they will work well together.
- Communication. Is it possible to describe what you want? Not everything can be written down and understood by everyone the same way. At this stage of the product lifecycle, there are a lot of opportunities for misunderstanding. Misunderstandings and miscommunication will lead to delays and defects that will impact the project negatively.
- Retention. Even if you find the right people at a time in their career when they are willing to make a change, make no mistakes in assessment and selection and manage to onboard them, the question of retention still remains. How will you keep the team member interested over the medium to long term? Engineers enjoy variety, switching contexts from time to time, and are always looking for challenges. Does your organization provide for that once the product has reached a more mature state?
- Cost of tooling. Consider the cost of new tools: how much will those cost? For example, a good oscilloscope can easily cost 10000 EUR. What will you do with it and a long list of devices after the project is completed, dramatically changed, or abandoned?
- Once you have hired the people, but need to abandon the product idea, you will now need to find new work for the engineers.
- Added risks in later stages. Unless you know the ins and outs of this stage of the product lifecycle, you might be taking on more risks with decisions made at this stage, that will tank the product later. There are known and unknown unknowns for taking a POC to the Alpha stage. For example: how do certain technologies scale? 3D printing vs injection molding, supply chain replacements, vendor capacity selection, etc.
Option 3: Partner with Krakul and…
- Enjoy a close-contact expert service focused on your business outcomes
- Implement lasting results in three months
- Gain certainty through simple, practical, steps that chart the progress and future of your product
- Tackle the big problems that are holding you back
- Work with people, who have done this before many times and are happy to help
Who is this for?
Again, this is for engineering managers, who are trying to deliver their IoT projects on time and budget but are struggling with managing stakeholder expectations and finding enough internal R&D resources.
Case Studies – see above
How It Works
Taking an IoT POC to an Alpha product in three months involves a three-stage process:
Step 1: Business
- Define and validate the business vision and requirements throughout the project. There will be workshops and meetings throughout the project, that create certainty and clarity in the way the product:
- Will be used
- Will be manufactured
- Makes money
Step 2: Process
- The project will be managed with short cycles and fast feedback.
We will work to anticipate change and to reduce the cost of change. Our cross-functional and co-located teams reduce miscommunication and delays. Assumptions are uncovered early. This will help the project end on time and within budget or the infeasibility of expectations will be discovered before major investments are made.
Step 3: Technology
- Keep requirements and design options flexible as long as possible and keep integrating and testing.
We will define the final outcome, but not how to get there in great detail up-front. We will decide what are the last responsible moments for making certain critical decisions. We will design with modularity in mind and use a high level of abstraction to leave room to make more decisions later as new information comes in.
The product will not get stuck by the limits of a specific technology when product requirements change. Thanks to constant integration and testing, problems and risks are discovered early enough to make course corrections.