- A Different Way to Run an Airline
- Frame 1: Customer Focus
- Frame 2: System Capability
- Frame 3: End-to-End Flow
- Frame 4: Policy-Driven Waste
- Portrait: Product Champion, Take 1
- Your Shot
This chapter is from the book
This chapter is from the book
This chapter is from the book
Portrait: Product Champion, Take 1
We close out this chapter by taking a look at what is probably the most important part of the system development process—even though it happens before most people would think the development process has begun. Before you dive into developing a system, it is critical to define its purpose in customer terms, just as you defined the purpose of your organization in customer terms earlier in this chapter.
When Thomas Edison invented the light bulb in 1879, it was a rather useless novelty. So he invented an electric power distribution system, formed a company to distribute power, and built a steam power-generating plant—to make the light bulb broadly useful. Edison's genius lay in his ability to envision how people would want to use light bulbs and to imagine a fully developed marketplace. We saw this same genius in Steve Jobs, as the iPod and iPhone came to life as complete ecosystems. This is the essential challenge of development: imagining how people will want to use a product and envisioning a complete system and fully developed marketplace. We call this ideation.34
Just as Edison went on to found the companies that brought his light bulb to the masses, we expect that ideation leaders will remain at the helm as their concepts are implemented. After all, people develop a certain passion around their creative ideas and are eager to bring them to life. In honor of that passion and dedication, we call this leader a product champion.35
A product champion, much like an entrepreneur, has business responsibility for the success or failure of the product. This means that for a product with a profit-and-loss statement (P&L), they are responsible for the P&L of that product. This is why the product champion leads the ideation effort—if ideation is not done well, the product will not be successful.36
For the sake of simplicity, we use the term product champion, although we recognize that you may not use the word product to refer to your systems. You may be developing
- Software as a product
- Software embedded in a product
- Software enabling a process
- Software under contract
In the first two cases, the product champion should be the person with business responsibility for the final product. With larger systems, the champion may need assistance with subsystem leadership. Even then, division into subsystems should not be along technology lines, but along subsystem lines, for example, an engine for a car, a medical device programmer, the human interface for an electronic device, and so on.
In the third case—software that enables a process—it is particularly important that the product champion (actually, in this case, the process champion) be responsible for the design and success of the overall process, not just the software.
The fourth case—software developed under contract—is the most problematic for a product champion, especially if the contracting party divorces software development from the rest of system development. In the end, software developed under contract serves a broader purpose, and it would be best to have a product champion responsible for the broader purpose guiding the learning and feedback necessary for system development. We recognize that this is not always possible, but in any case, the product champion(s) must keep the whole system in mind.
A product champion leads two critical activities: a customer-facing role and a technology-facing role. Very often these roles reside in one person, but they can also be successfully shared by two people working in close harmony. In either case, the product champion initiates development by leading a team through the ideation phase.
Customer-Facing Ideation
IDEO is a design firm in California that has been extraordinarily successful at discovering unmet needs and matching them with technically feasible, commercially viable designs. These have led to a remarkable lineup of products that have been extremely successful in delighting customers. As design awards pile up year after year, IDEO has gone into the business of helping other companies copy its design process.38
IDEO's design approach is outlined by general manager Tom Kelley in The Art of Innovation:39
- Understand the market, the client, the technology, and the perceived constraints on the problem. Later we often challenge those constraints, but it's important to understand current perceptions.
- Observe real people in real life situations to find out what makes them tick; what confuses them, what they like, what they hate, where they have latent needs not addressed by current products and services.
- Visualize new-to-the-world concepts and the customers who will use them. Some people think of this step as predicting the future, and it is probably the most brainstorming-intensive phase of the process.
- Evaluate and refine the prototypes in a series of quick iterations. We try not to get too attached to the first few prototypes, because we know they'll change. No idea is so good that it can't be improved upon, and we plan on a series of improvements. . . . We watch for what works and what doesn't, what confuses people, what they seem to like, and we incrementally improve the product.
- Implement the new concept for commercialization.
We can find no better summary of how to go about ideation. First frame the problem with its constraints. Then become an ethnographer and carefully observe people in that frame. This isn't about focus groups or market studies; go and watch the people who will use the product. Get inside their heads.
The next step is to visualize, model, and discuss what was observed. Add to the mix a forward-looking view of technology trends over the next few years. You want to skate to where the puck is going,40 and our technology puck moves fast. Brainstorm, concoct scenarios, tell stories about customers, whip up some prototypes, keep ideas alive.
Visualization leads to evaluation, a series of quick experiments that incrementally improve the product. "It doesn't matter how clever you are, your first idea about something is never right," says Tim Brown, CEO of IDEO. "So the great value of prototyping—and prototyping quickly and inexpensively—is that you learn about the idea and make it better."41
In due time, a product concept is ready for implementation. Ideation should not be a long, drawn-out affair, and the resulting concept should be at a high level to leave plenty of room for further learning.
Technology-Facing Ideation
Envisioning the product from a customer perspective is not enough in software development. Without an equally effective technology vision—let's call it an architecture—you aren't ready to proceed. The same design steps that worked to create a customer-centric view of the product can be used to develop the architectural vision:
- Understand: Technology is forever changing. Start by understanding where it has been and, especially, where it is likely to go over the life of the product.
- Observe: Take some time to observe the people struggling with the problem, from a technology point of view. The technical-facing concept and the customer-facing concept gain their integrity as a system when they are developed together and inform each other.
- Visualize: Model, discuss, brainstorm, test ideas with spikes.42 Inform these discussions with a keen awareness of where technology is heading and what will be possible over the life of the product.
- Evaluate: Don't get caught up in the first idea that comes to mind. Experiment. Select three or four options and use set-based design during implementation to make the final choice. Above all, remember that a good software architecture is one that facilitates change in the code over the short term and evolution of the architecture over the long term.
- Implement: At this point the architecture is a technical vision that will grow and evolve as development proceeds and learning takes place. It's time to start implementation.
The ideation phase will be done when it is done; it shouldn't have a deadline. It's not that ideation takes a lot of time; it usually doesn't. But without a breakaway concept, there can be no breakaway product. So don't short-change this important step. Develop a clear vision of how the product will meet market needs, how the architecture will support that vision, and how development will proceed. We call this a product concept. A product concept is not a detailed plan; it is a framework for proceeding with development.
What is the difference between a detailed plan and a framework for proceeding? Think of it this way: Plans are subject to change as learning occurs, whereas frameworks provide a space for learning to occur. So if you find that you have to make substantial changes to the product concept after approval, it was too detailed and did not provide for learning.
How do you know when ideation is done? This differs from one context to another, so we don't have a canned answer. In companies with good ideation processes, the product champion knows when the concept is developed sufficiently to move on to implementation. If you aren't quite sure, you'll have to experiment and find out what works for you. We recommend that you start your experiments with a bias toward action. If you wonder whether you're ready to start implementation, the answer is probably yes.