Core concept

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 

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:
    1. Will be used
    2. Manufactured
    3. And make money

What can I do right now?
Consider the following questions:

1. 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.
2. 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.
   
3. 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.
4. 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.
5. How will you analyze the data?
6. 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:
   1. The fleet of Beryl Bikes generates passenger transportation data that can be used by local governments when making infrastructure investment decisions.
   2. Audi now manufactures cars, that have the same capabilities, that can be activated by software.
   3. 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?

1. Make a price and availability assessment across the value chain for
   1. Components
   2. Connectivity
   3. Supply chain / Component sourcing assessment.
      1. 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.
      2. 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.
2. Component availability
3. 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.
   1. 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.
   2. 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:

1. Marketing
2. Sales
3. Development
4. Production
5. Delivery

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?

1. 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.
2. 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.
3. 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.
4. Test with all stakeholders, including the end-users, as early as possible.
5. 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?

1. 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.
2. 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?
   1. As a rule of thumb:
      1. Up to 1000: use as much off the shelf components as possible. (Exception: specialized military gear)
      2. 1000-10 000: balance off the shelf and custom components.
      3. 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.
   2. Communication and localization infrastructure. How will the device communicate?
   3. External: no connectivity, cellular, Bluetooth, WiFi?
   4. Internal: CAN, Ethernet, industrial protocols, etc
   5. Do you need to act in or just sense the environment? Actuators and sensors (temperature, humidity, noise).
   6. 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?

1. Make sure the product is architecturally sound and that the different layers work well together.
2. Refer back to the business vision and requirements. Is the product meeting expectations? If not, adjust accordingly.
   1. 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.
   2. 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.
      

Activity Summary

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.

Your Options

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.

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.

Warning 

As an expert close-contact service, we’re committed to delivering outstanding quality to our clients. As such we only have the resources to work with three new clients per month.

So, act now to secure your place with us, or we may have to delay our engagement together.

Guarantee / Bonus

Of course, we back everything up with a guarantee. Meaning if we don’t deliver on our promises, you don’t pay a dime.

We offer a full money-back guarantee at the end of month one if you don’t see progress toward your goals. Simply put, if we don’t bring at least our fees’ worth of pragmatic, implementable progress to your product, then you can get your money back.

If you agree to be a shareable case study we’ll provide you with a 5% discount. Please mention this at the time of your call with us.

Summary

What you get from us is:

• Support for defining, designing, and engineering your next Alpha stage product
• Keeping stakeholders and decision-makers satisfied and the product financing secured
• Meeting the necessary timeframes, cost, and requirement targets

Q&A

What are your manufacturing capabilities?

We have limited prototyping capabilities, but we prefer to work with partners because that gives more flexibility in our designs. We have a vast network of partners that we can bring into projects as needed. We don’t want to pigeonhole our customers to use the wrong technology just because we happen to already have it in-house. However, we will help you in setting up the production chain.

Can’t my existing team do this?

In short: if they could have, they would have. 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 they 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.

Have you worked in my industry before?

We have worked with many different industries over the years. Our key advantage is in helping our customers pair their industry knowledge with our IoT, business, and project management skills. If you manufacture brake pads, we will not tell you how to manufacture brake pads, but we can help you with new lines of business and implement new technologies in your operation.

How many product ideas should I work on simultaneously?

Ideally one POC per product owner. We are able to staff multiple teams to work with several product owners, but the focus and dedication needed to bring a product successfully to market should not be underestimated. We help our customers to identify the highest-value opportunities and to bring them to market as quickly as possible, gather feedback, make money, and to make decisions about next steps then.

How much will this cost me again?

We will agree on a fixed initial monthly fee in our initial strategy call that will be sized appropriately for your business’s and product’s scale and complexity.

How big is your team?

Its been big enough to serve multiple enterprises and start-ups with a global presence simultaneously for many years. Should your project exceed our existing team and our closely-knit partner network we will let you know. So far this has never been the issue.

How quickly could you grow your team if needed?

We use cross-functional teams that can be split in half and joined by new members. This means there will be no drawn-out ramp-up times.

How would your team integrate with ours?

We work both on-site, in a hybrid arrangement, and fully and off-site. With one of our customers we regularly fly to Los Angeles for key meetings, user feedback and integration events. We have worked locally with our customers in Europe, Asia and America. Our work continued during lock-downs when our customers were unable to visit their own offices. We integrate our teams deeply with those of the customer. In some projects we have daily, in others weekly calls in addition to everyday communication in Slack and other spaces.

We only work with our internal team of engineers.

You would be astonished at how many of our best customers have said the same thing initially. We help our customers with an end-to-end team that can be used as one of their own teams with a specific target of responsibility. Our ability to integrate well with different parts of the customer’s organization has been a key part of our success. It has helped our customers to achieve better outcomes without unnecessary disruption. It has helped our customers to bring in fresh ideas and perspectives and to keep from breathing in their own exhaust. These skills stay behind with the client’s people even after we leave.

I have tried doing product development with an external partner and it did not work. The partner tried to maximize hours and decrease risks with more meetings and extensive documentation. The solution was always another meeting or another document.

We are sorry to hear that. All partners are not created equal. A signed document is not a good indicator of progress. A working product increment usually is. Try to assess the partner’s ability to cooperate and to deliver value as early as possible. If the deliverable is another piece analysis, you should start asking questions.

If I outsource my team, I will be back at square one after the Alpha release.

While parts of the design and development process can be outsourced, key parts need to be in your organisation. If the product owner role stays with you and your partner has helped you to come up with user story based requirements that detail the what and why something needs to be built, you will be able to remain partner agnostic. A specific technical solution to a problem is not in itself of high value without business context.

Now is not the right time to begin. We have one or more POCs ready, but we can not get the funding for them.

Usually, this is a sign that the business case is not strong enough to get the decision-makers to agree. Look closer at the business case, validate its assumptions and map out the funding decision-makers and their goals. We can help you with that. Our outsiders perspective has been helpful in bringing people together and finding answers to difficult questions.

How can you guarantee my project will be successful?

We can’t. In about a quarter of the projects at the POC to Alpha phase, the product undergoes major changes in either the business requirements, customer segments, or technological approaches. This has helped our customers to identify more lucrative opportunities and to delay or give up on less fruitful avenues.

I am not interested in the POC to Alpha stage, but I need help with other stages.

We have helped our customers at all stages of the product life cycle. For example, when you want to optimize mass production due to changes in technology or component availability, you need the same approaches as described at the POC to Alpha phase.

Can you help me with regulatory compliance?

We have helped our customers achieve regulatory compliance in the US (with the FCC) and in Europe (with CE). Many of our team members have professional experience working in highly regulated industries. Tell us more about your needs and we will be able to tell you whether we can help you.

Can you help me with manufacturing? Our unit costs are still too high.

This is one of the key stages to be solved before reaching the Alpha product phase. Here are some of the steps we would review. We would help you make a price and availability assessment across the value chain for

• Components
• Connectivity
• Supply chain / Component sourcing assessment
• Component availability
• Cost and complexity of scaling