Presenter: Bill Allen "Marketing doesn't know what they want." "Engineering takes too long." Many such classic complaints are often more about organizational roles than about you or other specific people. In this session, you'll learn a simple visual framework that will illustrate inherent tensions in product development, help you work better with other functional groups, and build your credibility throughout your organization. As a product manager at Bose, Bill led the development of the original Bose Wave Radio and more than 10 generations of Lifestyle music and home-theater systems, oversaw the division's product-development process, and directed and published weekly marketing-staff write-ups of global research into products, markets, emerging trends & regulations, and competitors’ businesses. At Bose, he also managed the development of more than a dozen apps. Bill now works at RacerXInc.net to help manufacturers deliver connected benefits to unconnected products and as a consultant to help product makers build better products and development processes.

1. 1

2. Maybe product development should work like this, where somebody [asks] for what
they want, and [then] somebody [delivers] it. But this model quickly breaks down. At
my hotel, I asked “Would you have a paperclip?” “[How] many do you need?” “Just
one” “Two” “One” So it’s easy to get into some kind of loop. Francisco’s story.
2

3. Here’s a more complete model. You start by deciding what you [want]. That
[describes] a [gap]: the difference between what you have and what you want. That
gap [drives] developers to [do] some work, and that begins to [close] the gap. But
doing that work takes [Qme]. Maybe you need to ship on Tuesday, so there’s
[pressure] to want less. It’s easy to forget about the gap, but it’s really [important].
3

4. The gap is the agreement between the people who want things and the people who
do the work to deliver those things.
4

5. You can describe the gap with a product brief or a product definiQon. [or]
5

6. With a spec. At Bose, we also used a document called a Plan of Record.
6

7. 7

8. As a product gets developed, MarkeQng’s definiQon gets more mature, and the
Engineering documents get clearer and more complete. The conversaQon shi[s from
[what] you want in a product, to how your team expects to achieve that. At Bose, we
built a development process that had separate phases for the what and the how.
8

9. Aligning on what you want before figuring out how to deliver it makes parQcular
sense for developing consumer electronics hardware, but the general approach is
valid for many kinds of products.
9

10. This model helps describe the people in the different roles. The people who do things
someQmes wonder “[Why] do they want so much?”, and the people who want things
wonder “[Why] do they take so long?” [or]
10

11. The people who want things wonder “[Why] can’t the do the impossible?”, and the
people who do things wonder “[Don’t] they know what impossible means?” [So...]
11

12. ...this model only describes some of the mechanics of product development. But we
can add things to make the model beaer, and to improve its outcome. For example,
you can make beaer requests if you’re armed with [knowledge], and you share it
generously. You’ll build your credibility and ask for products that are more likely to
succeed. Building [skills] in how you ask for features, and how to prioriQze their
development will help developers understand what they’re supposed to do and give
them the freedom to be your creaQve partners.
12