Battle for Share of Market Part 3 — Planning for (Early) Product Deployment
Your early deployment pilot is to enable successful and scalable deployment of your product. This is the real deal. No slides, mockups or slick videos. Rubber meets road.
This post is for non-technical founders who need a better idea of what they are getting into, and technical founders working to communicate with non-technical co-founders and partners. It is intended to provide an initial framework for meaningful conversation. It is not exhaustive.
The first step is to define the goals of the pilot in more detail, starting by defining what you believe the Customer Value is going to be, how you produce and supply the needed Value Add, from what inputs, and how to measure the outcomes.
For example, if you need to integrate into your customers workflow, you’ll need to know the workflow, and what your interfaces will be. These interfaces can be interpersonal (verbally communicated instructions and data) or physical (mechanical coupling, electrical power connections, …) or logical (software instructions ….)
The primary metrics you will need to track are:
- The metrics of expected benefit to your customer. (Usually boils down to reduced costs, increased sales, or an emotional/sensory outcome as in the case of many consumer products)
- Your process metrics. These could map to input costs, system latency, process stability and quality, scalability, elasticity and more.
Logically, your pilot also validates your market and related economics.
Planning your pilot to define and demonstrate your value-add is another way to cross-check your assumptions and build a solid market entry plan.
Lets pick a few examples
I’ve explored cattle inspection and wireless communications below, which I hope will provide a reference for planning your deployment that also validates your early stage market entry planning and market-fit assessment. It is generally useful to think about these issues early in product / company development before committing funds and energy.
I have avoided repeating similar points in the examples; combining and parsing for your needs is recommended.
Ex 1: Cattle Inspection and Treatment
This example is inspired by my friend Joshua Dowell, who grew up on a dairy farm in Chowchilla, CA and took me around a few dairy operations — while peppering me with questions — as we drove across 1000’s of miles of California from Sacramento to Brawley.
Suppose you decide to develop a machine to automate pre-emptive antibiotic dosing for cattle by sticking a spray bottle up the nose of cattle and delivering a metered dose.(That, by the way, would be phenomenal on its own, with many interesting applications.)
To do this, you’ve built amazing computer vision capability with robotic controls. This also allows you to load up to 100 doses onto your robot. And the delivery nozzle gets exposed to focused UV light after every dose, ensuring constant sterility. It is just beautiful.
Let's call this CattleShot. You have dreams of selling CattleShot around the world, including India, since you know there are a LOT of cows in India.
As you start planning, you find out the need for antibiotics is more relevant in scenarios where cattle live in crowded conditions. In other cases like open ranches, the cattle are less disease prone. That puts you into feedlots and dense dairy operations, a smaller market.
CattleShot is really cool and will cost customers only $100,000 to buy, install and operate for a year and you firmly believe it pays for itself in a year. But you don’t like the smaller market.
So you go to India to find more cows and the meaning of life. Then you find out the village labor cost is about $1/day to $15/day depending on location. Plus the villager can deliver a dose by spray or needle and is competitive against you — and can also check out the rest of the cow for injuries and disease symptoms before calling the vet. So you fail to make much headway in India, even in India’s extensive dairy operations. And while you did not yet find the meaning of life, you discovered a whole new cuisine, and with that you come back to the US to regroup. But now you know the labor cost model will also define the actual TAM and SAM.
So your updated pilot metrics must take into account:
- The time for each operation and its labor cost. Can you support the throughput needs? What drives throughput? How do you round up cattle without calling in more resources?
- The dependencies for each operation. If one operation is automated, does it eliminate the need for human intervention? Or migrate that need to some other task? In other words, do you really make the automation impact you think you do?
- The dexterity of your value proposition. How easily do you fit into an existing process? How easily can your process be modified to fit other needs? What are the costs of doing so?
- What are the fixed costs? What investment is needed upfront? What would the payback period be? Are there dependencies based on predictions vs actual issues?
Now, you go to the feedlots; they focus on fattening bulls to be sold into burgers and steaks. The life expectancy of a bull in the US is brutally short. All the feedlot manager wants to know is if a bull is sick, and where that bull is located. CattleShot is interesting, but no go.
You go back to the dairy farmers. Now you find out that when they put cows in the cattle chute, as in the picture, they also inspect the eyes for pink eye, and the hoofs for damage or infection, and the teats for mastitis. In other words, the actual antibiotic dosage is a small part of what needs to happen.
It also turns out, the cost of the antibiotics is baked into the care contract with the vet. The vet has more impact on the herd than you thought.
At this point, you regroup once more, and talk with more dairy farmers, especially the thrifty ones. (Only the thrifty ones stay in business, so you need to talk to those ones.)
Turns out, happy cows make more milk, are less disease prone, and consume less antibiotics anyway. And that means a happy cow has reduced input costs, and generates a higher revenue. The pilot now gets a chance to be defined more precisely — and also tightens up your plan.
How do you know the cows are happy?
Well, they are mammals and sentient, so they’ll have emotions, heart-rates, heart-rate variability, breathing signatures, stress hormones and give-away signs of stress — tail whisking, lethargy, crankiness and a lot more. Just ask the dairy farmer and her family, and they’ll tell you. (Do take notes on spotting cranky cows; this will come in handy should you continue.)
So, now you dig into the technologies for detecting these metrics, and find that you can indeed obtain externally observable signals about these physiological processes.
Now you need to figure out what makes a cow happy, so you can keep them happy. Turns out, observation comes in handy … just be patient and keep a video camera handy. Think about stimuli, the metrics of the stimuli, measuring the responses, and correlating all of these to economic results.
Now all you need is a friendly dairy farmer with a herd that has some variety in ages and genetics, about $10 ~$40 worth of sensors per cow, about $2000 for a larger sensor that could work remotely for the herd, and the need to run remote identification and tracking of cow-happiness metrics.
This level of machine learning, noise rejection and analytics is not trivial, but then, actionable value is likely locked in there. (There could be an NSF/ USDA grant hidden in here. It will take work. )
Then compare to the farmers metric of liters of milk, fat content per liter, per cow, per day, and to your financial needs and reverse engineer to see if this is something you can afford to do.
Or put another way, your pilot plan needs to be a scientific experiment, with detailed research, analysis, planning, data capture, information extraction and follow on action. This will also serve you well in grant applications to fund your efforts.
Ex 2: Wireless Communications
This example is inspired by my friend Connor Cunningham who learned more about radios than he planned, and asked me endless questions on myriad topics over 1000’s of miles of California highways and byways from the foothills to the valleys.
IoT, IIoT, Industry 4.0 …. the drumbeat of acronyms and expert opinions are everywhere. Once the noise settles down, data has to be moved and processed into information, recommendations actions, dependably, securely and privately. This could in vehicles (Vehicle to Vehicle Communications, V2V), or in remote monitoring systems, or in factories.
Wireless communications can generally be broken into radio, lightwave and acoustic methods at the simplest level. The most common are radio and lightwave, with radio generally dominant.
Radio Testing and Related Planning
You will need to think about some common parameters, the possible errors that may arise, and how to avoid these by design, and focus time on key proofs.
Use tools like https://www.keysight.com/us/en/products/network-test/performance-monitoring/ixchariot.html if you can. Or build your own “close enough” with antenna’s, data sources and data sinks.
Use a precision GNSS receiver from https://www.u-blox.com/en to get centimeter level positional accuracy in 3-D space, and use Google earth for terrain mapping before you deploy — look for places you will get shadows. (Phone GPS systems are good enough for many estimations, but be aware of their accuracy limitations if precision becomes essential.)
What is the desired range of the transmission? This traces back to basic feasibility.
- You can transmit data using a cheap patch antenna, with line of sight (LoS) over 25KM without much effort, using unlicensed bands and a reasonably tall tower. Specificity in antenna, data rate, protocol and shared access to the channel are some compromises.
- There are off-the-shelf modems that can deliver 5 Gbps over 25KM without much hassle. Just do a search. They are excellent for range extenders.
- Doing long-haul wireless this with optics is brutally hard. I would avoid this. Many have tried.
- Short-range communications (like your TV remote) can work with dispersive lenses, and other options.
How much alignment is needed between transmitter and receiver? This also traces back to basic feasibility.
- Maintaining alignment between optical transceivers for sustained data transmission in free-space is possible, but brutally hard. Variable weather conditions, including wind, rain and dust, is challenging for affordable optical methods. Avoid this if you can.
- For radio systems, you can use the simplest of antennas, basically a wire, or a directional antenna (Yagi antenna’s etc.) Antenna “gain” goes up when the signal is more concentrated into a smaller aperture. This can create dead spots, that are often easily overcome with a unity gain antenna based on a simple wire. Or put another way, don’t use “high gain” antenna’s if you don’t need to. Save your time and money.
The length of the wire needed for the antenna is dependent on the frequency — use this resource to start with. You can go deeper later.
https://www.ti.com/lit/an/swra046a/swra046a.pdf
How much data needs to be transferred over radio? This traces back directly to the data needs of your use case and in turn drives protocol selection and energy budget.
- If you are transferring video or files, WiFi is a pretty good choice. It is a standard, software drivers are available, and complete modules are readily available. Note on WiFi and farming: WiFi in the 2.4GHz band is on the same band as a microwave oven. It is not advisable to use WiFi on farms, unless your signal is well above canopy or in an open space.
- If all you need to do is move a few bytes, sub-GHz radios can be used. Personally I like LoRA for this, especially where there is poor cell coverage.
- In the US, T-Mobile now has access to the 600MHz band, which extends their range significantly. This may open up the use of 4G and 5G modems to you. https://www.t-mobile.com/support/coverage/t-mobile-network for more information.
- Mesh networks require repetition of data from one node to other nodes to work as a true mesh, with server side de-duplication — or the use of algorithms for dynamic routing through the mesh. Bottom line, if you are latency or energy concerned, I would think really hard before using mesh approaches, especially with higher data rates, whether sustained or intermittent.
- Note that the EU and AUS allow for scheduled data transmission in the 400 MHz band, while the FCC does not. If you have funds and the need to, a licensed radio could also work, but your component selection drops. (John Deere has their network, as an example.)
What is the reliability of the data transfer needed? Can errors be handled? This traces back to whether your users can trust your systems.
- If you can handle intermittent loss of data, use methods without acknowledge. Note also that in an environment with marginal radio performance, implementing an “Ack” requirement can lead to multiple re-tries that will clog up your radio channel and lead to more errors.
- Testing for data loss and reliability should be part of your pilot plan. It is easy to do; just keep transmitting data in a time series and look for missing data on the receiver side.
- If data integrity is important, look for protocols that support error correction first, like LoRA, then look at forced Ack / Retry as a last resort.
How many participants need access to the communications channel? This traces back directly on the operating cost of your network and the capital cost of deployment.
- The number of devices on your network matters. If you try to orchestrate on/off cycles, you will spend a lot of time in doing so — as you unpack what is needed for this, it gets complicated without additional cost and power. This is doable in powered systems with GPS-clock at additional cost. However clock drift is real, and ongoing time-correction becomes an issue. So, you need to plan for a network with random participants, which means some channels may be randomly occupied at all times.
- Your channel capacity is inversely related to channel occupancy, which is directly related to the length of time you need to register onto the radio network and establish credentials, then transmit data. If an Ack is needed, this adds extra channel occupancy time. So, plan to minimize data payloads and pre-compress/ encode wherever possible. Then get off the channel as quickly as possible. Use variable rate transmission if your protocol supports this, to minimize channel occupancy.
- Testing for channel occupancy — and therefore actual vs theoretical channel capacity — should be part of your pilot; if your devices are on-air longer than needed, something is wrong and can take your network down. (Note that this is also a cyber-security problem.)
Summary
The end-user value, must be described in terms of measurable parameters. Make sure you capture the needed data, correlate the data to outcomes, and be sure to show the resulting economic benefit to your customer.
Good luck!!
This posting was as a result of multiple requests from readers like you. Feedback and suggestions for future topics is always welcome.
