Putting the end first: The Amazon way on IoT
February 03, 2017
Amazon is on the short list of companies that have already leveraged Internet of Things (IoT) technologies and practices in a way that is disrupting i...
Amazon is on the short list of companies that have already leveraged Internet of Things (IoT) technologies and practices in a way that is disrupting industries from consumer products to logistics. In this interview with John Rossman, partner at Alvarez & Marsal, former manager of the Third-Party Selling and Enterprise Services businesses at Ama-zon, and author of “The Amazon Way on IoT,” he describes how leveraging Amazon’s practices of starting at the end can put companies at the forefront of disruption in the IoT.
What are common misconceptions when someone wants to transform their company into an IoT company or transform their products into IoT products?
ROSSMAN: One is that they see it as primarily a technology challenge, and they don’t understand the business impact, the ecosystem impact, the full opportunities, or the change that they’re going to have to undergo from a skill set and management technique standpoint. The second is that, especially when they’re really doing some-thing innovative, they don’t understand that failure and innovation go hand-in-hand, and that if these are truly “bets,” the nature of a bet is that a high number of them are going to fail. So, while they talk a game of wanting to be innovative, they really don’t understand that it’s a highly unpredictable game. You need to think about your portfolio differently when you’re in the innovation game versus when you’re in the investment game. You can use IoT on investment opportunities like operational improvements to reduce cycle time, improve quality, and reduce the cost of internal processes, but those are going to be incremental improvements and less innovative types of scenarios.
Are companies you deal with encountering challenges in moving from static to iterative development processes for IoT?
ROSSMAN: It’s a fine balance between designing to specific use cases but doing so in an extensible way so that as you learn, get feedback, and gain experience you can more easily migrate into other opportunities and use cases. You want to be careful about not building yourself into a corner, so on one hand you have to focus on spe-cific use cases and on the other hand you have to remain open to opportunities that could come along. You have to think about it as a journey as opposed to “We’re building to this specific end point and then we’re done.” The concept of extensibility is really important as you build and think about your IoT roadmap. You have to migrate from the mindset of “Build a product. Launch a product. Get Revenue. Move on.” That’s the challenge.
Oftentimes, the metrics of success are not revenue – it’s about engagement or adoption or other types of impact. The more innovative it is, the more of a bet it is, the more you have to deemphasize the financial evaluation and emphasize the true measures of adoption so that you can learn something. The fail fast, agile mentality and hy-pothesis-driven betas and early prototyping is really, really critical. Most management doesn’t understand that, but it’s one of the most defining features of systematically innovative companies like Amazon. They understand that notion between “How do we measure and manage a portfolio of innovation bets?” versus “How do we measure and manage a portfolio of investment and scaling what we’re already doing?” Those are very different portfolios.
Also, in one of the chapters of “The Amazon Way on IoT” I write about the fact that an IoT product could be your entre into becoming a platform company, and letting other enterprises find value based on the attributes of your products and services. Becoming a platform company has some very important – some dramatic, some sub-tle – changes that need to happen in order to be able to do that well. Some companies miss the notion that there is a platform opportunity and how to go about building an ecosystem in order to address the “below the water line” opportunities that IoT can present. One of the things the Amazon Echo demonstrates, for example, is this notion of being a platform. By being a platform, you allow other companies and other developers to innovate and lever-age on top of your core capabilities. In the case of the Echo and the Alexa software that powers it, companies are able to create skills and have their products and experiences leveraged in the Echo.
What’s your advice for those looking to develop an overarching product or company-wide IoT strategy?
ROSSMAN: In the book I walk through a checklist that addresses this. The steps are listed in a sequential man-ner, but I emphasize being iterative, skipping steps where possible, and inserting steps where you have to insert steps that work for you. It’s a fairly quick and fun way to get a clear vision, help bring stakeholders along, and create an orderly-enough plan to execute against the first leg of a vision.
I broke it into three main parts that are purposely geared towards a fast and iterative strategy, plan, and approach that has energy and is in the style of what you might see a company like Amazon do. They are: Develop and articulate your strategy; build your IoT roadmap; and identify and map your IoT requirements.
John Rossman’s Amazon IoT Checklist
Part 1. Develop & Articulate Your Strategy
- Create a landscape analysis
- Create value-chain and profit-pool analyses
- Create partner, competitor and vendor analyses
- Identify customer needs
- Create evaluation framework
- Articulate your strategy
- Build your flywheel model
- Create your business model
Part 2. Build Your IoT Roadmap
- Small but informative starts
- Write a future press release
- Create an FAQ
- Create a user manual
- Build a project charter
- Project objective
- Initiative description and deliverables
- Major milestone
- Team
- Metrics, measures, and goals
- Assumptions and dependencies
- Risks
- Duration
- Budget
Part 3. Identify & Map Your IoT Requirements
- Insights (data and events)
- Analytics and recommendations
- Performance
- Environment and operating requirements
- Costs
Strategy development always starts with a landscape analysis: What’s going on in the industry? What are my competitors doing? Where is the investment money going? What are analogous industries doing that might be interesting to us so we’re well informed? Every company, even if they’re doing nothing in IoT, at least needs to have their antennas up and study the environment. Then it’s really about identifying your customer needs. You can do this in lots of ways, but it’s really about understanding the customer goal or frustration and what piece of data or event could be highly valuable to them or to you. How can IoT play a role in that?
Using what we called the flywheel model at Amazon, which is just a systems dynamic understanding, you realize that IoT is highly dependent on partners, ecosystems, and integrations. You need to understand that flywheel and how to create a virtuous cycle, and what the resistance points are going to be against that strategy. Those are a couple of tools you can use to create a compelling reason and strategy for what you’re going to do, and then use it to get a team on board.
For building your IoT roadmap, I walk through a set of things that we would typically do at Amazon. It would start by writing a future press release, then we would write an frequently asked questions (FAQs) page, a user’s manual, and then build a great project charter. All of these things are about starting with the end in mind and gaining as much clarity as possible before you start creating requests for proposals (RFPs), hiring vendors, cut-ting code, buying devices, and doing any of that sort of stuff. You’ve got to slow down and create a compelling vision. At Amazon we put a tremendous amount of energy in this phase of it because we believed that was where the magic moments happened, and what separated creating okay products from really good products. It’s the clarity of what you’re trying to solve up front.
The final phase is taking all of that and identifying your IoT-specific requirements: the specific data and events that you want to collect, the operational requirements of your devices, how operational support happens, as well as all of the backend infrastructure that might be necessary relative to those. But you can’t skip to doing those types of requirements if you don’t have the prerequisite knowledge and clarity going into it.
Some teams and some scenarios have the clarity up front to do a proof of concept (PoC), and if you can go right to building, fantastic. The checklist is comprised of activities and deliverables that, if you can skip doing, I abso-lutely would. But especially in corporate environments, there’s a tremendous amount of consensus building and education that you have to do. The things I walk through are the things that you find yourself needing to do in order to do something an IoT pilot.
What is fundamental to creating a successful IoT business?
ROSSMAN: I think of three layers of the IoT cake. On the lowest level, it is about the technology. The sensors, the communications and data transport, the cloud infrastructure, and the algorithms and the event management. That’s necessary. The middle layer is the use cases that tie everything together. The frosting on the cake is the business models that are really going to create value. Any of those definitions are the right definitions, and it just depends on what layer of the cake you’re talking about.
The fundamentals are truly understanding the customer scenario, well beyond whatever your product or device may be trying to fit. At Amazon we talked about customer obsession – truly understanding the broader problems, values, and things that your customers are trying to get done. That will give you insight into the problems you’re trying to solve and the role you can play in those challenges. Oftentimes in IoT that’s going to force you into partnerships and integrations with other upstream and downstream products and capabilities in order to truly solve that broader customer experience problem.
Alvarez & Marsal