Conclusion: Developing Your IoT Strategy and Plan

Beware of the man who knows the answer before he understands the question.

—ANONYMOUS

It was a dreary February early morning in 1999 in Portland, Oregon, and my good friend and longtime mentor, Steve Maupin, and I had just delivered an inspiring, value-building, and compelling integrated-supply-chain and manufacturing strategy to the senior leadership team of a forest-products company.

The CEO, at the surface a crusty forest-products operator but at his heart a sophisticated sales and operating executive, sat back after the presentation. Steve and I, standing up front, waited with the rest of his leadership team in silence. We had been retained to do an enterprise planning resource (ERP) software selection for his company and, as part of this, had built this integrated-supply-chain strategy.

The CEO looked up and, slowly, without emotion, started. “I drove in this morning in a good mood. I went and saw a baseball game with my son last night. Business is good. So I’m trying to understand why I’m so mad right now.” He turned to Steve and me.

“Have you ever heard the term RTFP?” he inquired.

Steve and I shook our heads no.

“RTFP stands for ‘read the f—— problem.’ If I had wanted an integrated-supply-chain strategy, I would have asked for one.” What he was really looking for, or so he thought, was a software strategy, and so we quickly went on to the software-selection part of the agenda.

Steve and I laugh about this term, RTFP, and story. In the case of the forest-products CEO, we hadn’t worked hard enough to help him see the opportunity and the connection between the software he wanted and the integrated-supply-chain strategy we presented. These days we often refer to RTFP when collaborating on a client situation—usually in terms of how to help our clients start a project off with better questions. This notion of how to ask better questions has become foundational in how I attack problems.

In the course of my career, I’ve estimated and planned hundreds of projects. I’ve learned that, even before you start seeking answers, it’s imperative to understand the questions. Guiding a team to a successful outcome on a complex project requires understanding of the steps and deliverables, necessary resources, and roles and every inherent risk and dependency.

Before starting the hardware and software design, before figuring out how to engage developers, before planning the launch party, you should start with a better set of questions.

In this section of the book, I’ll outline the set of tools that have helped Amazon and I ask the right questions to think through and plan IoT businesses. We’ll talk about how to apply these tools and strategies to your business and how to use them to build your own understanding, communicate your vision to your team, and identify the requirements and next steps for your IoT business.

A note on sequencing: Though I’ve outlined all of the following steps as sequential, they’re often actually done concurrently, and there are many ways to approach them. I’ve outlined them here in the most likely progression, which I feel helps lead to a top-down development of insights, but don’t feel trapped by the order.

I recommend using the checklist located at the end of this book to help you guide and keep track of your IoT planning. I’ve included an example for some of the tools, but it is easy to find examples and tutorials on all of these tools in books and online.

As you build your plans, remember that though IoT can provide key pieces to the puzzle, it’s no golden ticket. Simply creating an IoT solution will not bring you success. However, if you focus on providing strong value to your customers through new or updated products and services, improving company operations, or creating new or more-efficient business models, you’ll be much more likely to find success.

It might be obvious to you where the IoT opportunities lie in your business. You may see clearly how to proceed; that the organizational implications are minimal; that the work to be done is mostly technology oriented. If that’s the situation you are in, there’s a chance you should proceed directly to go, collect your funding, and enable a smart device.

But in most circumstances, to lay the right foundation, understand the breadth of the opportunity, and develop understanding and support in the organization, there is work to be done before proceeding to construction.

PART 1. DEVELOP AND ARTICULATE YOUR STRATEGY

Michael Porter, professor of strategy at Harvard, has said that “the essence of strategy is choosing what not to do.”⁶⁰ In the wide array of opportunities you likely have with IoT, narrowing and prioritizing is the first step. The point of this first set of exercises is to allow you to narrow smartly by developing an understanding of the market and deliberate evaluation of your opportunities. Doing this work up front will allow for more scale and sophistication.

1. Landscape Analysis. Drawing up a thorough analysis of your industry, competitors, strengths, weaknesses, opportunities, and threats (SWOT) will help you understand the backdrop, the megatrends, and the forces at play in your market. Understanding these factors will set the stage for a successful IoT play through heightened awareness of threats and weaknesses. But the landscape analysis also feeds into a deeper understanding—dare I say obsession—with your customers and their environment.
2. Value-Chain Analysis and Profit-Pool Analysis. Next up is creating your value-chain analysis and profit-pool analysis for your industry. Make this a broad view of the industry, not just a narrow view of your current business. You’ll remember Amazon’s deliberate “launch and learn” strategy from principle 9: Launch a business in one part of the value chain, and then use that opportunity to learn about the rest of the value chain and identify other possible business opportunities. Although we didn’t produce an explicit value-chain analysis, working this way taught us all the lessons we might have learned if we had.

   

3. Partner, Competitor, and Vendor Analysis. It’s amazing what you can learn about what’s going on in your industry on a topic like IoT by creating a map of other solutions providers in the space. You should use this exercise to develop a clear understanding of what exactly each does, who their key clients are, and what their use cases are in the IoT landscape. You should also pick a few to interview. This is helpful preliminary work in developing a plan for partners and vendor selection. It’s also a less direct route to Amazon’s first leadership principle, which you’ll remember is customer obsession. Understanding partners, competitors, and vendors will help you begin to see the needs of your customers, the smart way those needs are already being met, and the gaps in the way those needs are currently being met. As we’d say at Amazon, “It’s OK to use other people’s good ideas that weren’t invented here.”
4. Customer Needs. Developing customer personas and mapping those customers’ current journeys is a great way to document specific unmet needs and identify key friction points your future customers are experiencing right now. Following the path from start to your desired outcome can help you identify details and priorities that might otherwise be dealt with at too high a level or skipped over entirely.

       Crafting strong customer personas and journeys is hard work. It’s likely you’ll need to iterate a few times before you really nail them. (I oftentimes need to start over more than once before I gain any real insights.) The biggest mistake you can make on these is to build them for show rather than for work. Don’t worry about the beauty of these deliverables until things are getting baked (if at all). Do worry about getting at insights, talking to customers, and validating your findings with others who can bring insights and challenges to your work.

5. Evaluation Framework and Scoring. The next step in the process is to design the ways in which you will assess the success of your work. This includes understanding a project’s feasibility and transition points and how it will tie into other corporate strategies at your company. Sometimes, especially if your organization is new to the field of connected devices, the success of your project should be measured in terms of what you can learn from the project rather than whether or not it can be classically considered a success. In this case, evaluate for situations that can present lower risk of impact if “failure” occurs. Remember, failure is great, as long as the impact can contained and minimized. Some of your early initiatives may be purely to gain experience with no expected ROI.
6. Strategy Articulation. Once you’ve done all of these analyses, it’s time to articulate your learning to the rest of your team. Like the rest of these steps, there are many possible ways to articulate your proposed strategy, but there are two in particular that I have found to be most effective in clarifying and communicating strategy—building a flywheel model of your business systems and articulating a business model.

CONSTRUCTING YOUR FLYWHEEL MODEL

A flywheel, or systems-dynamic model, helps identify, validate, and communicate the ways that the different forces and dynamics in your business are connected. It helps you understand whether those forces reinforce or work against each other.

One of the benefits of working hard on a flywheel model is that it will help you either see opportunities or identify competitive risks in the industry or scenario you’re considering. It will help you understand how to overcome inertia and create momentum, establishing reinforcing feedback loops along the way.

“Companies that pursue a flywheel-business model focus on building the kind of long-term capabilities that allow them to prevail against rivals and capture new opportunities for growth.”⁶¹ Before you get started, I recommend rereading principle 10 for a full description of how to go about creating your own flywheel model.

ARTICULATING YOUR BUSINESS MODEL

In my experience, the most logical next step after creating a flywheel model is to dive into the development of your business model. I like to use a business-model canvas or template to articulate and explain the many facets of a business model. These template-driven approaches help a small team quickly think through broad issues. They are fun and easy to facilitate and help keep energy high as you build an iterative and appropriate level of documentation.

To help clarify and explain important differences between options that I’m thinking about, I typically develop multiple business-model canvases. They’re a great way to outline and clarify minor differences between partnering models and revenue models and identify key choices around building or partnering on platform components that you’re considering.

Business Model Generation, by Alexander Osterwalder and Yves Pigneur, is a great source for both standard and in-depth business-model templates. For IoT-focused business models, you’ll need to adapt these models. I recommend using the following questions to adapt Osterwalder and Pigneur’s models for IoT-centric opportunities:

• What data would be valuable if a sensor could collect it?
• What efficiency or valuable insight could be developed by an algorithm (don’t focus too much on the feasibility yet)?
• What add-on or new services or insights could be developed? Are there new customer opportunities?
• How could ecosystem partners (oftentimes software and solution developers) help in both distribution and capabilities development and differentiation?
• What are the potential revenue models for a given business model?

Once you’ve designed your flywheel and business model, it’s time to get company leadership on board with your plan. It’s important that they be both well informed and supportive of your plan if you want it to succeed.

From there, it’s time to build your IoT Roadmap.

PART 2: BUILD YOUR IOT ROADMAP

Where strategy articulation helps you explain what the big idea is and why you should do it, the IoT roadmap helps you plan and communicate to others what the journey will be like to get there and add clarity to exactly what is being built and how it will work.

In creating your roadmap, embrace one of Amazon’s favorite strategies—think big, but bet small. Here’s a reminder of the leadership principle explored in my first book: “Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold vision that inspires results. They think differently and look around corners for ways to serve customers.”⁶²

But don’t confuse “thinking big” with “betting big.” Once you have a big vision, you’ll need to make a small bet to test your thinking. This is particularly true if your fully implemented ideas would have a big impact on existing customer experience or products or if they would shift your business model. A prototype that’s lower risk in terms of financial or operational risk can allow you test a big opportunity, theory, or idea. Be iterative, build prototypes, and fail fast.

Companies that do this well will out-innovate those that don’t. A prototype isn’t the only way to test this—creating minimally viable products or jointly developing a project with your existing customers and partners are also good options for minimizing the size of your bet and making experimentation more feasible.

Here are a four specific ways that teams at Amazon might think differently about kick-starting their IoT programs. Each step will clarify your strategy and build toward a greater understanding of what success might look like. By articulating the specifics of your future success clearly, you will also help your team understand the specifics of what it would to get there.

THE FUTURE PRESS RELEASE: DEVELOPING AN ORGANIZED VISION

Bezos is famous for requiring teams to create a “future press release” before launching into a new product, undergoing any kind of transformation, or entering a new market. Going through the process of creating a simple but specific product announcement forces you to find clarity around your vision. You have to think through key features and adoption and weigh your project’s likely path to success. Putting all of this down in a press release, speculative though it may be, also helps you express these things more clearly to important stakeholders. We used this future-press-release approach at Amazon, and it has been a consistent tool I use with clients. They really love it.

The future press release is a great approach to define clear and lofty goals, requirements, and objectives and build broad understanding from the start of a program or enterprise change. There are, however, rules to make this approach effective:

Rule 1. The goal must be stated at a future point in time where success has been achieved and realized. Press releases at launch are good, but a better one is sometime after launch, where true success can be discussed.

Rule 2. Use the release to explain why the product is important, oftentimes to customers (or other key stakeholders). Discuss the accomplishments in terms of why it is important to customers. How did the customer experience improve? Why does the customer care? Then discuss other reasons it was important and key goals.

Rule 3. Set an audacious and clear goal. Articulate clear measurable results you’ve achieved, including financial, operating, and market share results.

Rule 4. Outline the principles used that led to success. This is the trickiest and most important aspect of the future press release. Outline the hard things accomplished, the important decisions, and the design principles that led to success. Discuss the issues that needed to be addressed to achieve success. Getting the “tricky” issues on the table early on helps everyone understand the real nature of change needed. Don’t worry about discussing how to solve these issues yet. You’ve still got time to figure that out.

Once you’ve created a future press release, the project leader needs to be empowered to make these changes happen. Focus on creating a future press release oriented communication plan that helps that project leader find success across the organization.

The future press release is a type of forcing function. Once the press release is reviewed and approved, teams have a difficult time backing out of the commitments made. A leader can refer to many parts of the press release and use it to remind and hold teams accountable. It paints a clear vision to galvanize understanding and commitment.

AN FAQ FOR YOUR IOT PLAN

Once you’ve written a press release, you can forecast some of the questions you’re likely to get about your product in a frequently asked questions, or FAQ, document. The purpose of the FAQ is to add more details to the press release and answer other business and execution questions necessary to launch. This can be either a separate document or appended to the end of your future press release.

By proactively writing an FAQ, you’re forcing yourself to think through what the key questions about your product will be and helping to answer the big questions your stakeholders are likely to have.

A good FAQ allows the press release document to stay short and focused on what the customer gets. The FAQ should include resolution and answers to issues and questions that come up when you are writing the press release. It should also respond to questions that arise through the process of socializing the press release. A good FAQ includes questions that define what the product is good for, how it will be leveraged by the customer, and why it will delight the customer.

The FAQ forces you to put yourself in the role of the customer using the product and consider all the challenges or confusions you might have. It also provides inspiration for designing a fully self-service, confusion-free product.

USER MANUAL—START WITH THE END IN MIND

Developing a preliminary user manual for your IoT device can be a powerful tool early on in a project. We used this at Amazon when developing products or APIs. Your IoT user manual should address at least two key customer segments.

1. The End User of the IoT Device. Who is the customer that will be installing, using, adjusting, and getting feedback from your IoT product? Outline what the unpacking directions will be, what the installation process will be, how updates will happen, what the data privacy terms will be, how to use and read the device, and how to connect it. Think through all the major steps the users of the product will need to take, and include them in a close-to-real-life user manual. Forcing to keep these steps simple will lead to great product ideas, user experience, and technology design.
2. The Programmer Developing to Your IoT Device and API. If your IoT product will include an API allowing developers to access, deploy, integrate, and extend your product, then you’ll also want to build a user manual for the developer. Write out the interface for the API, what events will be supported, and the data to be sent and received. Give example code snippets and outline key operational topics such as how testing occurs and how operational status and updates are facilitated. You’ll also want to use this exercise to outline key business and use terms. Are there charges involved?

As you can see, all of these techniques strive for three things:

1. Breadth of thinking through use cases and requirements
2. Clarity around the experience—what it will be, how it will work, and what it will provide
3. Simplicity to drive easy-to-use products

PROJECT CHARTER

A project charter is a written project overview outlining the key facets of a project. The project charter is the part of the IoT roadmap that helps you take what you’ve decided to do and put it into action: What resources will you need to make this happen? What are the key milestones? What’s the schedule for accomplishing these things? Often, project managers rely solely on GANTT charts to plan a project. The project charter adds other topics and nuance to the planning process.

Planning starts with the process of taking ideas and strategies and articulating how you will go about the objectives of the project. Deeper project plans will oftentimes be appropriate, but the project charter is a lean approach to project planning and estimating. It’s essentially the ninety-day plan for what you’ll do to get your project going. I developed this template over many years of scoping and communicating projects to a diverse set of stakeholders. The key elements of the project charter are as follows:

• Project Objective. The simple and minimal description of the initiative and why it matters. This can be the “elevator” speech for describing a project and why it is valuable.
• Initiative Description and Deliverables. A deeper breakdown of the objective and discussion of the high-level deliverables to be created through the life of the project.
• Major Milestone. Using the description and deliverables, outline key milestones for the initiative.
• Team. Who are the people, and what are roles needed for the initiative? Place focus first on the full-time resources needed and then on other contributors. Focus on the roles needed to actually do the work versus roles to review the work.
• Metrics/Measures/Goals. Articulate the quantifiable goals for the initiative. Focus on customer-oriented measures wherever possible and then business-impact measures. These are not metrics for the project itself but instead tied to the impact this capability will have.
• Assumptions and Dependencies. What are the critical capabilities, organizations, projects, and so forth that are critical to the success of this initiative? These are often “unproven” or still in delivery, but identifying them outright will help to flag places you may want to be thoughtful in facilitating collaboration throughout the initiative.

Many issues in a project emerge due to a lack of clarity—“I thought you meant this” is a refrain you don’t want to hear during a project. By diving deep into dependencies early in the project planning phase, you can hopefully avoid these kinds of issues coming up later on in the project.

As leaders at Amazon, we were carefully coached to avoid these kinds of surprises. The fourteenth leadership principle, deliver results, instructs company leadership to “focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.”

While planning key initiatives, we were focused on our dependencies. In most cases, those dependencies were teams and capabilities we were not in direct control of but that were critical to our results. We often received lectures about “managing our dependencies” as a way to remind us of the risks in our delivery plans. Dive deep into your dependencies, and outline the schedules, risks, metrics, and critical aspects.

• Risks. Articulate the most critical risks to delivering this vision. I recommend not repeating items already listed as “assumptions and dependencies” section. This is not a “cover your ass” (CYA) exercise but a value-oriented process to help identify and communicate risks and what might be done to either avoid, mitigate, or accept.
• Duration. For this first leg of the journey, start estimating and setting expectations for the duration and potential range.
• Budget. Identify the typical spend and real budget needed for this project: tools, facilities, expenses, contractor, and consultant spend and perhaps initial marketing or communications are key categories.

The beauty of this “project-on-a-page” template is that it gives a well-balanced view of what the project is. It’s a useful tool not only for developing your own understanding of the project but to use as a consistent reminder of the project’s principles to everyone involved.

PART 3. IDENTIFY AND MAP YOUR IOT REQUIREMENTS

The last step in creating your IoT roadmap is to create a set of IoT requirements—the technical capabilities you’ll need to put in place to make your solution a success. Using and referencing your charter, the creation of which we outlined above in part 2, will help you develop the requirements of what you’re going to build.

Companies use many different types of approaches, such as use cases, user stories, process flows, personas, architecture specifications, and so on to document their requirements. Regardless of the requirements methodology you use, I have found that considering and answering the following set of questions is an important part of building IoT capabilities or solutions. You might be able to specify requirements just by answering these questions.

Insights (Data and Events)

• What problem, event, or insight is the end user solving for?
• What insights would be valuable to the customer?
• What recommendation or optimization using the data would be valuable to a customer?
• What risks or nonconforming situations might impact the customer? How could your product, perhaps partnering with other devices, identify these risks?
• What data needs to be collected?
• How often does it need to be collected?
• What types of events, forecasts, or “optimizations” could be identified or derived from sensors and data?
• Does the data need to be combined with any data or events not resident at the device?
• Will data and events be combined across devices?
• Who else (users, devices) will subscribe to the data?

Analytics and Recommendations

• How responsive will “adjustments” or optimizations need to be (specify in time range)?
• How complex will the “math” be? Write the math equation or pseudologic code if you can.
• Will notifications, logic, “math,” or algorithms be consistent and fixed, or will they need to be configurable, updated, and managed?
• Who else (users, devices) will subscribe to the analytics? Who needs to be notified of events, data, or analysis of data from the device (or devices)?
• How will they be notified?

Performance

• Estimate the amount of data transmitted over a period of time (hour, day).
• What are the consequences of data not be collected?
• What are the consequences of data being collected but not transmitted?
• What are the consequences of the device not being connected?
• How quick (in seconds) do alerts or adjustments need to be received by the device?
• How quick (in seconds) do alerts or adjustments need to be received by other subscribers?
• How close will the devices collecting data or subscribing to analytics be to each other?

Environment and Operating Requirements

• What operating conditions will the device and sensor be in? Temperature, moisture, pressure, access, and vibration are example conditions.
• What device physical-security needs or risks are there?
• Will the IoT device or sensors be embedded within another device, or will they be independent and a primary physical device themselves?
• How will the IoT device connect?
• How constant does the connection need to be?
• How reliable does the connection need to be?

Costs

• What is the cost per device target range?
• What is the cost per device for connectivity target range?
• What is the additional operating cost range the business can support for ongoing operating infrastructure?

Once you’ve completed all of your IoT roadmap deliverables—including developing and articulating each component of your IoT strategy and then creating your IoT roadmap—you will have all the essential elements you need to get to work building your IoT capability.

At this point, you know what you want to accomplish, you know why you want to accomplish it, and you even have an idea of how you want to accomplish it. Now, go accomplish it. Or as Yoda said, “There is only do or do not. There is no try.”

ALWAYS BE STRIVING

The death knell for any enterprise is to glorify the past—no matter how good it was.

—JEFF BEZOS

If you’re fortunate, the innovative IoT-enabled operational improvement or business strategy is obvious and well accepted across the organization, and you have the leadership support to drive all aspects of change necessary for success. For the other 99.9 percent of us, there’s hard work to do to develop the idea, build understanding, create the right environment for change, and get all the leadership alignment needed.

This chapter and the entire book have outlined some of the techniques that can be used to do this in a nimble, iterative manner. It’s OK if you’ve started with the technology and now are coming around to the business and change strategy—change is messy and doesn’t usually progress in a logical or ideal manner.

But why is innovation so hard? Why is a company like Amazon rated as a singular standout by analysts and peers as the number-one supply-chain company for being both operationally excellent and innovative?⁶³ Why is challenging the status quo so difficult? I believe the answer lies deep within our fears. I’m talking in particular about the fear of failure, especially once you are successful. The fear of breaking traditions.

In 2013, the TV commentator Charlie Rose did an interview with Jeff Bezos.⁶⁴ In discussing why Amazon is constantly pushing to invent new businesses, Bezos said the following: “Companies have short life spans and Amazon will be disrupted one day. I don’t worry about it because I know it is inevitable. Companies come and go. Companies that are the shiniest and most important of any era and you just wait a couple of decades and they are gone. I would love for it [Amazon’s disruption] to be after I’m dead.”

Companies that don’t let their past models and success define who they are will be those that span eras and define what comes next. A new era is upon us—the era of connected devices, driven by sensors, abundant connectivity, cloud computing, and machine learning.

Will you challenge your status quo and traditions to seize the opportunity of the IoT era?