Pragmatic Marketer Summmer 2014

t h e p r o d u c t m a n a g e m e n t a n d m a r k e t i n g a u t h o r i t y
summer 2014

2 pragmaticmarketing.com summer 2014
the product management
and marketing authority
Founder/ceo
Craig Stull
PreSIdenT
Jim Foxworthy
edITorIAL dIrecTor
Rebecca Kalogeris
edITor
Linda Zid
deSIgner
Norman Wong
SPecIAL ProjecTS
Sarah Mitchell
The Pragmatic Marketer™
8910 E. Raintree Drive, Scottsdale, AZ 85260
Interested in contributing an article?
PragmaticMarketing.com/submit
No part of this publication may be reproduced, stored in any retrieval
system, or transmitted, in any form or by any means, electronic, mechanical
photocopying, recording or otherwise, without the prior written permission
of the publisher. Other product and/or company names mentioned in this
magazine may be trademarks or registered trademarks of their respective
companies and are the sole property of their respective owners. The
Pragmatic Marketer is a publication of Pragmatic Marketing, Inc., and
Pragmatic Marketing, Inc., shall not be liable regardless of the cause, for
any errors, inaccuracies, omissions, or other defects in, or untimeliness or
unauthenticity of, the information contained within this magazine. Pragmatic
Marketing makes no representations, warranties, or guarantees as to the
results obtained from the use of this information and shall not be liable
for any third-party claims or losses of any kind, including lost profits, and
punitive damages. The Pragmatic Marketer is a trademark of Pragmatic
Marketing, Inc. Printed in the U.S.A. All rights reserved.
ISSN 1938-9752 (Print) ISSN 1938-9760 (Online)
Since 1993, Pragmatic Marketing has conducted product management
and marketing training for 7,000 companies on 6 continents. Our team of
thought leaders produce blogs, webinars, podcasts and publications that
product professionals around the world turn to for industry insights.
In politics, nothing halts progress like a divided
constituency. Red states vs. blue states. Liberals vs.
conservatives. Athens vs. Sparta. Each side is focused
not on moving forward or finding compromise, but on
placing blame.
Unfortunately, this same type of divide exists in many
technology companies between the product and the
development teams.
But this divide cannot stand. Because, as Mark Lawler
says in his article, only by working together can we
“deliver great products that delight those who are the
most important: your customers.”
Working together effectively means understanding each
other’s points of views and goals. This summer’s issue
helps you do just that, as contributors who have sat on
both sides of the technology aisle weigh in on everything
from methodologies to prioritization to the key artifacts
required for interdepartmental communication.
So grab a cup of coffee, pull up a chair and dive into the
latest issue of The Pragmatic Marketer. And when you’re
done, share the issue with your partner across the aisle
and start uniting your efforts for the common good.
Sign up for your free
subscription, delivered quarterly via email,
at pragmaticmarketing.com/subscribe.
Rebecca Kalogeris
editorial director
Sincerely,
product and development teams unite!

[departments]
i Bits & Bytes
3 Developer to Product Manager Q & A:
Felix Sargent | Road Warriors: India | Puzzles
i Build Better Products
22 How a Tech Background Empowers Product
Professionals by Scott Sehlhorst
24 Confessions of a Nontechnical Product
Manager by Julie Babb
i Sell More Stuff
26 Engage Your Audience with Google Hangouts by
Brandee Sweesy
28 Take the Guesswork Out of Content Creation
by Sandra Jean-Louis
i Lead Strategically
32 Speaking the Same Language by Dana Jones
34 Four Power Cues for Leaders by Nick Morgan
i A Pragmatic Approach
40 Put this issue’s ideas into action
[features]
Product Management Versus
Development: One Bag and a Carry On
by Mike Hughes
8
Why Marketing
Should Go Agile
by Jim Ewel
16
The Two C’s
of Agile
by Mark Lawler
11
7 Tips for Highly Successful
Requirements Management
by John Milburn
20
summer 2014 pragmaticmarketing.com 1
Share this issue >

Get your entire team on the same page
with our market-driven framework.
You may not actually start holding
hands and singing together after
our training, but you will start
working together more efficiently
and effectively.
Pragmatic Marketing’s courses
provide clarity on roles and
responsibilities, as well as the skills
and tools needed to execute those
roles successfully. So, whether you’re
working with development to build
the next great product, or with sales
and communications to sell it, we
have the course for you.
Your
kumbaya
moment awaits.
Visit www.pragmaticmarketing.com or call 480.515.1411 today.

Bits & Bytes
How did you become a product manager?
During one development project, I was the person who ended
up facilitating the discussions about what to build and the kind of
work that entailed. I worked to create consensus and made sure
everyone’s opinions were heard. Afterward, my manager asked me
if I wanted to be the product manager.
Strangely, I wanted to be a product manager
since I was young. My brother, who is 11 years
older, moved from England to America to be a
software engineer when he was 21. I grew up
listening to his horror stories: “I built out this
new feature that allows them to release new
updates without ever having any downtime
and nobody really noticed.” I wanted to be the
product manager he never had. That’s molded my
personality as I’ve worked.
do you fill tHe role tHe way you dreamed about
back tHen?
I love my job and have a passion for doing it,
but you would have to ask my teammates what
they think about working with me. I think my
experience as a developer is really useful, because
I can communicate and speak that language.
Part of my philosophy as a product manager
is that I don’t believe in strict adherence to
process, except to provide stability so people
know what to do next. When I read the “top 10
ways to organize your backlog,” I think the author is missing the
point by not talking to the people and finding out what’s driving
them crazy—and then figuring out ways to address those issues.
do you and your brotHer talk sHop wHen you get togetHer?
We wouldn’t work together, because we’d kill each other. But it’s
always nice to both complain and learn from each other. He allows
me to hear things from a different perspective, and it’s nice to
bounce things off each other for feedback.
do you ever miss being a developer?
The nice thing about being a developer is that you know when
you’re done. As a software engineer, you just
get into a state where you know you’re going
to squash a bug and fix things and they’re
going to be more perfect. I’ve seen many of my
product-management peers become incredibly
overworked, because they aim for perfection and
don’t know where to stop. There is no such thing
as perfection when you’re looking through the
backlog. Figuring out what to work on and what
not to work on is always a challenging task. It’s
impossible to perfect a plan before things change.
do you Have any advice for anyone wHo
wants to move from development to product
management?
You should prepare for “being busy” to be
different. As a software developer, it means you’re
always developing. Being busy as a product
manager is like being busy as a parent. It comes
down to being ready, not about fighting fires.
Instead of setting the direction, being a good
product manager is really about listening to the
direction as others perceive it—and then putting
that into a document that can be shared to create a touchstone.
You’re codifying the zeitgeist of what the team is doing and what
the team needs to work on in the future. In order to do that, you
need to be listening.
I think the best place to start is to know what a bad product
manager is. It’s much easier to define than a good one. A bad
product manager says, “Do this.” A good product manager says,
Q&A
Felix Sargent started his career
as a developer and now works at
Rackspace as a product manager.
many product
managers
become incredibly
overworked,
because they aim
for perfection and
don’t know where
to stop.

Bits & Bytes
“What do you need me to do?”
Managing well is like dancing well. There isn’t a series of steps
you follow and then you’re done. You need to interact and relate to
your partner and environment.
Do you have any aDvice for a new proDuct manager?
Put the kettle on and have some tea. Meetings are often painful,
forced, time-boxed, stressful and aggravating. At first, my team
and I were doing agile standup meetings, where there’s a time
limit, which makes people feel too uncomfortable to discuss much.
Developers are only talking about what they’re doing next so that
people are on the same page. But being on the same page doesn’t
always help. You also need to have a forum where people are
relaxed and safe, so they can say if they don’t like something—and
see if others are feeling the same way.
One afternoon, after a morning full of handling my team’s
issues, one of my engineers came to me with yet another request.
Admittedly, my brain was fried at the time and I needed a reset.
I’m English, so 3 p.m. is tea time for me and I find good tea to
be both calming and invigorating. It helps clear my mind and set
me on a productive path for the rest of the afternoon. I invited my
engineer to join me for a pot of tea, and we started discussing the
issue he’d brought to my attention.
We moved from our company kitchen to a set of comfortable
couches and talked candidly about the issues. Others wandered
over, listened in, aired their own
opinions and started solving
problems themselves. I poured
more tea and put on another pot.
As they talked, I found myself
hearing them in a new light and
finding opportunities where I could
make their work easier for them.
Sometimes, it was as simple as
clarifying priorities and helping them
understand deadlines. Other times,
it meant working with others in our
organization to better use APIs
or integrate code. For us, the key
to a good standup meeting was
sitting down.
Travel Tips for Road Warriors
Insights on India
Over the last 20 years, India has earned a reputation as a technology hub. But it also has
continually been celebrated for its beautiful scenery, storied history, exquisite fabrics and
foods rich in flavor. Here are just some of the sights this diverse country
has to offer.
Wildlife Tours
www.thewildlifeofindia.com
Take a walk on the wild side with a wildlife
adventure. People travel from all over the
world to catch a glimpse of the majestic
Bengal tiger in its natural habitat—and
if you’re lucky, you could also see langur
monkeys, peacocks, elephants and one-
horned rhinos.
Spice Farm
www.sahakarifarms.com
Some of the spices you will see on this
60-acre farm include vanilla, cinnamon,
nutmeg, cardamom, pepper, cloves, chili,
curry leaves, turmeric and ginger. Visitors
also learn about the different uses of spices in cooking and in the
treatment of common diseases.
The Bangala
www.thebangala.com
Be sure to bring your
appetite. Lunch here is
touted as being more
elaborate than a seven-
course wedding feast. Authentic Chettinad cuisine, considered
among the spiciest and most aromatic in the country, is served
up in plentiful portions on banana leaves. You can even request a
cooking demo or kitchen tour.
Tea Gardens
www.darjeeling-tourism.com
If tea is more your thing, Darjeeling offers up more than 80
operational tea gardens. Watch tea pluckers in action, stroll
through the beautiful gardens and learn about tea processing in
the factories where some of the best teas in the world are withered,
rolled, dried, sorted and packaged.
I find good tea to
be both calming
and invigorating. It
helps clear my mind
and set me on a
productive path.

Q Y K T D Q G Q E T
Z C R I E Z I U L N
A D H O N S P G I I
C G R I T X T D G R
C B L E C S S I A P
B U Q X L K R Q N S
T G X T E E E E E G
T S P E C S A N S R
B A C K L O G S C U
L A U N C H I G E P
Agile
Backlog
Bug
Chicken
Launch
Pig
Release
Reqs
Specs
Sprint
Testing
User Story
100100
010101
101010
111000
110011
001001
111100
011011
000001
110101
000100
111001
0 1 0 1 0 1 0 0 1 0
1 0 1 1 0 0 1 0 0 0
1 1 0 0 1 0 0 0 1 1
1 1 0 0 1 0 1 1 0 1
1 0 0 0 1 0 1 0 1 0
0 1 1 1 1 0 1 0 0 1
1 0 1 0 1 1 0 0 0 1
1 1 0 0 0 1 0 0 1 1
0 1 0 0 1 0 1 0 1 0
1 1 0 1 0 1 0 0 1 1
River Ganges in Varanasi
Product Puzzle
Binary Brainteaser
Konkan Railway
www.konkanrailway.com
Building of this railway line, which runs from
Mumbai to Mangalore, was considered
a technological feat because of the
formidable terrain and short construction
period. But that terrain also means you can
take in beautiful greenery,
rivers and mountains on
your journey. It is also an
opportunity to get a sneak
peek at how people in
some of the smaller villages
of India live.
Varanasi
www.varanasicity.com
Set on the banks of the
Ganges River, this lively,
colorful city is one of
India’s oldest and most
spiritual. It features beautiful
temples at every turn, soothing boat rides
and elaborate alleyways filled with shops
and local delicacies. Attend a puja, a prayer
ceremony, which takes place every evening
and features cymbals, bells, drums and the
casting of tea lights into
the Ganges.
Bollywood
www.bollywoodtourism.com
See the vibrantly colorful sets, locations
and studios that Bollywood is so well
known for. You might even meet a local
celebrity or be asked to be an extra in the
latest hit.
Wagah Border Ceremony
www.punjabtourism.gov.in
This ceremony at the border between
India and Pakistan has occurred every
night before sunset since 1959. A parade
of soldiers from both sides kicks off the
ceremony, and it ends with the pomp and
ceremony of the lowering of the flags from
both nations.
Tawang Monastery
www.buddhist-tourism.com
At 10,000 feet above sea level, the largest
monastery in India features majestic
panoramic views and peaceful serenity.
The monastery houses more than 300
monks, and is known for its thangka, a
painting on cotton or silk applique, called
Ja-Droi Ma that was painted with blood
drawn from the fifth Dalai Lama’s nose.
Fabric Tours
www.indiaquiltingandtextiletours.com
See, feel and buy beautiful fabrics; talk to
quilt-making artisans; and have clothing
custom made just for you. You can even
participate in workshops with local master
artisans and learn ancient Indian textile
arts like embroidery, bandhani tye dye, pit-
loom weaving, block printing and batik.

PM
Ask the Experts
T
his is one of The quesTions i receive mosT frequenTly. Should
designers report to development, engineering
product management, marketing or someone else?
Or should design be its own group?
To answer the question, we must first define “design.”
Even that has been heavily debated, but for now, let’s use my
definition of design:
Design is the role in a team that understands a market
problem, and comes up with a solution to that problem.
At a minimum, there are two flavors of design:
Front-end design. This is
what most people mean when
they say “design.” The titles
found in front-end design
include user interface, user
experience, human/computer
interface and human factors
designers. These are all
titles found predominantly
in software projects, but front-
end design is not limited
to software.
Front-end designers in
hardware applications are concerned with ergonomic design,
user fatigue, eye level, placement of power cables and
interfacing to larger systems. In services, a front-end designer
might think about how many key presses a user makes on
their phone when calling into an interactive voice-response
system before they can talk to a human.
Back-end design. Those involved in the back end are
often called “architects.” In software, they are typically
concerned with items like codebase choice, code reuse,
library selection, building scalable and secure systems and
whether to use Amazon EC2 or another cloud provider.
In hardware, they might choose the processor’s clock
speed or determine how much memory overhead would
accommodate future upgrades.
In both cases, design is measured differently than
product management and development. We teach that
members of the product team should be measured on
their effectiveness at bringing accurate market data into
the business to feed better decision making. Meanwhile,
development is often measured on a combination of scope,
time and quality.
But for design, measurement needs to answer several
core questions:
• Does the design effectively solve the user’s problem?
• Does the design fit into the user's daily life or workflow?
• Does the design act in a way the user expects it to act?
The bottom line is: Design is a huge role, encompassing
a wide variety of areas. It’s very rare that one person is highly
skilled at both front-end and back-end design.
In my experience, back-end design almost always reports
to development because of the intertwining technical nature
of the decisions these architects make every day.
Meanwhile, front-end design has migrated in the past
decade, reporting to development, then to marketing, then
to product management. It eventually became its own group
in some companies, and is also sometimes a contracted
resource that reports to the hiring party.
Like product management, there’s a natural tension
between front-end design and development (and marketing)
teams. This tension arises from differing (sometimes
competing) goals and measurements of success. Typically,
this tension is a good thing, but when we shove front-
end design under development or marketing, the tension
resolves in favor of whoever owns that team. For instance,
a development team who owns design and is measured on
hitting the date will naturally pressure designers to create
designs that achieve that goal—not necessarily conducive to
good designs for the user.
So who owns design? The designers, of course. And who
owns the designers? The goals of product management are
highly aligned with design, so I can easily see reporting up
the same structure. I can also see success as an independent
part of the product team.
But wherever you place design in your organization, have
an honest conversation about how designers are measured.
If you measure design like development or marketing, the
results will be suboptimal—and understanding that is more
important than where they sit.
Ask the Experts:
Who owns design?
Do you have a question for our experts?
Send us an email at experts@pragmaticmarketing.com.
Paul Young, Instructor
Pragmatic Marketing

80% of Pragmatic Marketing’s
business comes from alumni referrals.
I’ve built my career on
what I learned from
Pragmatic Marketing.
Find out for yourself what the loyalty is all about.
Visit www.pragmaticmarketing.com or call 480.515.1411 today.

I
hate the unnecessary inclusion of “versus” in titles and
headings, because it often implies an adversarial
relationship where one does not—or at least should
not—exist. But while product management is often the
greatest ally developers can have, there is some inherent
tension between the two. Product management usually wants
as many features in a product as possible, while developers and
UX designers typically don’t want to be held accountable for
fulfilling unrealistic expectations of what we can accomplish
in a single product release. Figure 1 illustrates this conflict.
In my current role, I do a lot of negotiating back and
forth between product management, their stakeholders
and my product-development team trying to refine a set of
requirements for a given product release or a roadmap of
releases. This reminds me of a study I did back in my doctoral
days, when I observed the differences between product
management and development during a particular product’s
development cycle. I summarized my observations using the
metaphor of a couple packing to go on vacation.
Product management is the visionary, the one who
imagines how great it will be when we get there and identifies
all the things we’ll need to make it an enjoyable experience.
They have an extensive list of things to pack—and frequently
change or add things to the list up to the last minute. “Certainly,
we’ll need flip flops for the beach, but we might go hiking on
trails, so we should bring our tennis shoes too. Oh, and let’s
bring some dress shoes for going out to dinner.”
The other, development, is thinking about getting there
and is focusing on getting everything into one bag and a carry-
on. Every time the former makes a change, the latter sighs
deeply and unpacks everything, making room to add the new
item. In some cases, this forces a swap with something already
packed. Every accomplished packer knows the code: One does
not simply throw a pair of flip-flops into a packed bag.
So to sum up, the product manager is the visionary, the
one who imagines how great it will be when we get there
and identifies all the things we’ll need to make it an enjoyable
experience. The developer plays the role of the packer, the one
who must fit all of that stuff into the constraints of reality.
Product
ManageMentversus
develoPMent:
one Bag and a carry-on
develoPer
Scope creep...
Deadline...
Budget...
By Mike hughes
Give me all
the stuff!
Product Manager
figure 1

Resolving the tension
The obvious question is: How does one eliminate the tension
between the two? I, for one, don’t think we should. I think the
essence of design is to resolve tensions, not eliminate them.
Some classic UX design tensions include convention versus
innovation and control versus freedom. In these cases, the
conflicting poles are not binary choices of this or that; rather,
they are like the opposite ends of a speaker balance knob. More
of this gives you less of that. The designer’s question is: What is
the correct blend, given the problem I am trying to solve?
So, from the developer’s point of view, the first step is to
recognize the validity of the product-management perspective
and the value it brings. Remember that the trip to the airport
and then to the vacation resort takes just a few hours. After
that, you’ll be at the resort for an entire week. The benefits of
packing lightly start to fade as you go horseback riding in flip
flops. Similarly, the appeal of an efficient set of requirements
that you can easily meet within the time and technology
constraints can quickly wane, as a thin set of features struggles
to succeed in a competitive marketplace. And in spite of your
best intentions to expand upon the current release in the next
one, the newest bright and shiny thing may have emerged.
It is likely that the thin release will have to sustain your
business presence in that marketplace, because there may be no
reinforcements on the way.
The second step, from the developer’s point of view, is to
recognize the validity of his or her perspective and recognize
the value of constraint. There’s no need to be apologetic or
shy about this. As the old project-management chestnut says:
Better is the enemy of done. Your vacation ceases to be any
fun at all if the airline doesn’t allow your luggage onto the
plane. You can’t enjoy being there if you can’t find your way
to get there.
some PRactical techniques
Here are two simple techniques that help me to manage this
productive tension between me and product management. One
consists of making all of the hard requirements decisions before
making any development investment; the other describes a
useful yardstick with which to make such decisions.
Negotiation through artifacts. Every good packer knows
the secret to packing is to stage everything before you begin.
For example, if I am packing a suitcase, I lay out all of the
clothes on the bed first. Similarly, if I am packing my car, I
put all the luggage and stuff we need to take with us on the
driveway first. Then I can make better decisions about what

PM
should go where and when I should put it there.
As a UX designer, I do the equivalent of staging when
I create scenarios and wireframes, essentially laying out and
agreeing on the user experience before we start investing
significant development time and resources. The fight over
what is in and what is out is a good fight; a fight that needs
to happen. It’s just not a fight you want to have when the
product is already in the middle of quality assurance. When
you inevitably start throwing things away, you won’t want
to have invested a lot of value into what you now
must discard. I think one of the greatest
values that user experience brings to
the table is our ability to moderate
these fights and negotiations by leveraging artifacts in which
we’ve made little development investment.
Minimum viable product. Eric Reis, a Silicon Valley
entrepreneur, popularized the concept of a minimum viable
product, and agile developers have adopted this approach as a
way of deflating large sets of requirements into manageable,
independent chunks of development work. Essentially, an
agile team asks: What is the least amount of functionality
our product has to have before users would find themselves
compelled to buy the product? This establishes the minimal
target: the point below which you would have wasted all of
your time and effort, because you would have nothing to
show for it that anyone would buy. For example, Notepad
or a similar text editor probably represents the minimum
viable product for a word processor. If you couldn’t do at least
that, you’d have nothing to take to market. Or stated in the
converse, if you could do at least that, you’d have something
someone would buy.
The nice thing about the concept of a minimum viable
product is that everyone on a product team can pretty
easily agree on the feature set that it represents. Establishing
this baseline clears the landscape for the stickier rounds of
negotiations, when you go through similar iterations of
finding the next group of features that represent the next most
important level of viability. For example, a next logical step
for Notepad would be to introduce more sophisticated text
formatting and allow rich text format (RTF) output. Adding
features that got you just halfway there would provide no
additional value. In short, you need to apply a sort of quantum
theory to feature sets, such as “anything that doesn’t jump a
gap that’s this big brings no value at all.”
When does this stop? When you run out of allocated
development resources.
I once worked for an online bill payment company that
wanted to design a financial planning application. To do this,
we wanted to know how people went about paying their bills,
so we did focus groups. Overwhelmingly, the most common
technique was to save one’s bills until payday, then sit down
and stack them in a priority order such as rent, car payment
and so on. Participants then started paying bills from the top
of the stack and continued writing checks until they ran out of
either bills or money.
That’s pretty much how we decide what goes into
a release, too. If we’ve run out of resources, but product
management thinks there are essential features that are still on
the table, they must reduce the requirements for other projects.
The end result of all this is that we have a reliable release
roadmap in which product management and sales have
confidence, because the packers keep the visionaries honest.
And we have releases that offer true customer value, because
the visionaries make sure the most valuable things get packed
into a release. At the heart of this are the UX artifacts—
like scenarios and wireframes—that facilitate productive
discussions without a lot of development investment.
About the Author
Mike Hughes is a user experience designer for TSYS, focusing on
applying user-centered design practices in agile development teams.
Before that, he was a user-experience architect for IBM Security. He
was formerly lead UX designer for CheckFree Corporation, where
he instituted their User Experience Research and Design Center.
Mike has a PhD in instructional technology from the University of
Georgia and a master’s in technical and professional communication
from Southern Polytechnic State University. He is a fellow with the
Society for Technical Communication and a Certified Performance
Technologist through the International Society for Performance
Improvement. He can be reached at michaelhughesua@gmail.com.
The fight over what is
in and what is out is a
good fight; a fight that
needs to happen.

O
ne of the most frustrating things i’ve heard over my
career is that “agile is something that software
developers do.” It is said dismissively by those who
are happy with how things are today and see no reason for
changing how they operate. It ignores all the success agile
teams have had in software the past decade and in other
industries including architecture, marketing, video production
and even the auto industry.
I’ve had the pain and pleasure of running both software-
development and product-management teams for well over
two decades—sometimes both at the same time. After being
involved in the agile transformation of almost a hundred
teams during this time, I can attest that agile truly works and
I can’t imagine ever going back to traditional waterfall. But
for agile to work, product management must focus on these
two key C’s: courage and customers.
C is for Courage
You have to have the courage to make hard decisions,
especially when prioritizing the features within a release and
defining the minimum viable product.
Before agile, this was very difficult. We had our list of
features, and we made them fit perfectly into the appropriate
swim lanes of our PowerPoint presentations. It took quite
a large chunk of our time to lay it out in a way that was
By mark LawLer
Going agile requires that product management
have courage and be the voice of the customer.
The Two C’s
–of–
agile
The Two C’s
–of–
agile

compelling and showed the promise of a coherent strategy.
After creating a product roadmap, which clearly showed
the priority and features for each major release, why
would research and development (R&D) need product
management to waste time on the prioritization of the
features within a release? The list is the list, right?
The ugly truth, and we all know it, is that R&D
under waterfall was rarely able to complete a release as
defined by the roadmap.
I once took over an organization where every
release was a battle, with tons of infighting. Why?
There were always serious tradeoffs that had to be
made once the software-development teams came nearer
to the scheduled ship date. R&D managers became the
captains of “we can’t.” And that forced their product-
management partners to ruthlessly decide which partially
completed or not-even-started features to cut to meet even
some of the major commitments that had been made. It was
always at the end of the release, and product management often
felt as though they had a proverbial gun held to their heads by R&D.
At the end of the day, product management believed it was settling
and that R&D was driving what features made it into the release. In this
organization, product management had courage, but it was courage in battle
and in finger pointing versus courage in planning and execution.
To attempt an armistice, the R&D teams held out an olive branch:
Prioritize your features, and we’ll ensure they are completed in that order—
sparing you those last-minute hard decisions of which features to keep or
jettison as we rush to complete the release. But product management simply
refused to prioritize their features. They dug their heels in, sending their
software-development manager a spreadsheet that had everything marked
as “high” or, my personal favorite, “must have” in the priority column. The
response from the software-development organization to their unprioritized list
came across as Draconian:
“Spreadsheets have rows and, unless you explicitly state the priorities without
any ties, we are using the row numbers as the priority. When capacity runs
out, that is the cut-off line. If you want to change your mind and add a new
requirement to the release midstream, it will insert a new row in to the list and
all those rows below it get pushed down on the list. This will cause one or more
items you thought you might get below the cut line as the team runs out of
capacity. It is what it is. Deal [with it].”
R&D saw product management as lacking the courage to prioritize and
absconding responsibility. And R&D, lacking courage to work with product
management in true partnership, chose instead to let the rows of a spreadsheet
step in as the proxy priority. As with most dysfunctional teams, each side
continued to play the victim and with less than spectacular results. There were
incremental improvements, but only in that it became much more visible what
capabilities would be delivered in what order.

After introducing agile into the
organization, things took a great
turn for the better, albeit after a very
rocky start. Agile forced the priority
discussion with each and every sprint or
iteration versus only at the beginning or
end of a traditional release cycle. As part
of sprint planning, the product owner
and scrum master work in partnership
to prioritize which user stories are to
be worked on in the next iteration. The
goal of this new approach is that the
highest priority items are worked on
first. And at the end of every
iteration, one can ask, “Do we
have a shippable or demonstrable
product? Have we reached
minimum viable product?”
This organization, as I
mentioned, had a rocky start.
Product management initially
viewed agile as “a development
thing” and refused to play the
role of product owner on all
the teams but one. “We’ve
handed the development team the list
of features we need to include in the
release, why would we spend time
prioritizing not only the features within
a release, but now for each and every
3-4 week iteration? Scheduling how
they do work should be their job.”
The unfortunate result was that
for those teams, R&D invoked their
own C—the C found in “cherry
picking.” Without real guidance as
to the priorities, the individual R&D
teams simply picked and chose
what user stories they worked
on and why. Some were
selected because they were
the easiest, while others
were chosen because they
contained the most interesting work.
Unfortunately, the end result for
these first agile teams was a cacophony
of capabilities, spread like a wide
shotgun pattern across the feature
list. When schedule pressures forced
product management to become
involved to triage, the mess they found
seemed worse off with agile than it
had been with waterfall. At least in
waterfall they had a glimmer of what
R&D was working on as there was a
schedule that showed tasks. With agile,
they had what appeared to be random
tasks completed without care as to how
everything fit together. How were they
going to tell a story to customers or
management about the major themes
and value behind the releases, when
what they had now looked like a
patchwork quilt? “Down with agile”
was being shouted from the rooftops;
all that was missing were the pitchforks
and spires.
One team, however, had gotten
agile right and it showed the
others the best path. On this
team, a technical product
manager had shown
the courage to embrace
this new methodology
and became the product owner. She
quit writing market requirements
documents (MRDs) that resembled
tomes and manifestos, choosing instead
to embrace the much easier user stories.
She also became an active participant
in iteration planning, prioritizing user
stories in the backlog and partnering
with the scrum master to assign them
to the next iteration.
With each iteration, she was
able to demonstrate to management
a product that was evolving during
its development cycle. And
she was able to get feedback
early and often from her
customers and even incorporate
that feedback into future
iterations—sometimes even
in the very next one. She
discovered that the R&D team
still never made it through the
entire list that was initially
planned for the release, but
there were no more last-
minute hard decisions about which
partially completed features to rush
to completion or to mothball. She
knew with confidence when she had
a minimum viable product and it was
easy for her to tell the R&D team: “Halt
the presses, lock this thing down and
clean up the rough edges I’ve laid out in
user stories in the next iteration—and
let’s get it out to our customers.”
Other product-management teams
saw this as an anomaly vs. a true
testimonial to how great agile could
be. After all, a single data point doesn’t
make a trend.
The good news is the product
manager of this newly successful
team became quite vocal in terms of
With each iteration, she
was able to demonstrate
to management a
product that was
evolving during its
development cycle.

how her R&D teams were no better or worse than the other
teams. She openly shared that the key difference was that
she had the courage to jump in with both feet and to follow
the best practices of hundreds of other software development
agile teams across many industries. She surveyed where the
practices had worked and where they hadn’t, went to agile
user groups and then had courage to take the plunge. The
other product managers eventually came around, albeit slowly
at first.
As each team started to kick in and make the transition to
what management considered to be high-performing teams, it
became harder and harder for the laggers to hold on to their
old ways since their teams were not getting any better while
the others’ clearly were.
In a nutshell, having the courage to fully embrace agile
allows you to:
• Force prioritization at every sprint to avoid last-minute
difficult decisions
• Get feedback early and often from customers—and
incorporate that feedback into future iterations
• Be vocal and lead by example to get the whole
organization on board
C is for Customer
One of the best aspects of being in product management is
bringing the voice of the customer to your product delivery
teams. Although we have a plethora of boxes to cover in the
Pragmatic Marketing Framework, being that customer voice
is one of the keystones to ensuring success at any and all of
them. And as a proxy for the customer, we are expected to
travel at least 25 percent to 50 percent of the time in order
to stay in contact with all customer contingencies (sales,
marketing, professional services, partners, customer support—
and yes, customers, both current and future). Some people I’ve
met along the way have never understood this and they can be
the death of their agile teams.
Being agile helps facilitate incorporating the voice of the
customer by eliminating MRDs as thick as a New York phone
book. You know the documents I’m talking about: Those that
describe everything a product was to do in excruciating detail,
but are rarely read, understood or executed on.
Instead, agile allows teams to focus on “user stories,”
requirements that are “fit for purpose” and scaled down into
bite-sized chunks. These stories follow a format that looks
something akin to:
I, as a <user role>
Want to <goal or outcome user is to accomplish>
Because <the reasons why a user in that role would
want to do that>
Acceptance criteria: <list of criteria by which a product
owner would call that story done or completed>
A process called “backlog grooming” takes place next.
When a user story is too big for an R&D team to accomplish
during an iteration, it is broken down into smaller stories that
point to its parent story (often called an epic or a feature in
agile-speak). Where the story isn’t clear or lacks acceptance
criteria, the product owner uses the voice of the customer
to make it even clearer. Here is a golden opportunity for the
product owner to express everything that R&D is to work on
and to clearly tell them both the “what” and the “why” for
each and every requirement. Because the product owner is
supposed to be the proxy for customers and their voice in all
product discussions and decisions, product management often
plays this role.
That leads me to what I believe are two poor choices for
product owners:
Proxy product owners. While it’s true we no longer
need huge MRDs, for some this has morphed into writing
no documentation at all for the R&D team. In these
organizations, the R&D team has no choice but to play the
role of product owner, which further helps perpetuate the
“agile is a development thing” belief. In those organizations,
I call the folks who step up “proxy product owners.” It isn’t
One of the best aspects
of product management
is bringing the voice of
the customer to product
delivery teams.

out of disrespect for what they are doing. In fact, it is the
exact opposite: It is acknowledging that they are playing a
role outside of their organization and taking on extra work
that is very important to the success of the product. It is also
an acknowledgement that they are indeed acting as a fully
empowered proxy.
Some view this as software-development organizations
not focusing on the “how” and wandering dangerously into
the “what” and “why” that product management is supposed
to own. My answer is simple: Have the courage to play that
role and be that voice of the customer; R&D shouldn’t do it,
nor does it want to.
Those who don’t believe in visiting customers. This is an
even worse type of product owner on an agile team. All too
often they are subject matter experts (SMEs) who believe
that they know all of the answers based on their vast years of
experience—that they, due to their personal previous work
experience, know much more than the customers they are
supposed to serve. Now don’t get me wrong, not all SMEs are
this way. But in my career, I’ve run into a number of them,
especially in specialized industries such as healthcare where
subject matter expertise is held out as being more important
than actual product-management expertise.
One product-management organization I had the pleasure
of taking over after an acquisition was loaded with SMEs who
served as product owners, but never spent any time on the
road talking with customers. They did so only at yearly user
conferences or when there was an escalation and they were
forced to deal with an angry customer. When I drilled down
and probed on why each of them didn’t visit customers, the
answers that I received were:
• I’ve worked in this industry for years before becoming a
product manager.
• I know this industry like the back of my hand, and I
know what is best for our customers.
• Our customers don’t know what is best for them, and
as an expert in this field, it is my job to come up with
those things that make life easier for them.
Wow! Really? If a product owner on an agile team is
supposed to be the proxy for the actual customer, wouldn’t
actually talking with customers be a critical part of the job?
I would contend that if they are basing everything they do
on their own personal experiences, being hunkered in their
bunkers versus out there in the real world, then their agile
teams are simply building solutions for one and only one set
of customers: themselves.
In this organization, I had no choice: I put SMEs on
the road to actually meet and talk with customers. In their
requirements and user stories, I had to advocate that the voice
of the customer always be incorporated. Those who couldn’t
get beyond their own greatness as SMEs and still refused to
talk with customers were given other assignments where their
knowledge could be tapped and leveraged. These holdouts,
however, no longer had the role of making everyday decisions
regarding the course of what had once been their products.
Incorporating the customer in agile allows you to:
• Drill down to the basics in short user stories versus
long MRDs
• Communicate both the “what” and the “why” for
each requirement
• Have customer conversations before it escalates into
angry confrontations at yearly conferences
Take agile acTion
Over the years, I’ve seen two types of product-management
organizations:
1. Those who embrace agile and cherish the glory of
how much they can accomplish in partnership with
development.
2. Those who do not embrace agile and sit on the
sidelines, sniping at the teams that can never give them
what they want, when they need it.
To create the first type of organization, you need to have
the courage to jump in and be that voice of the customer in a
way that helps your development teams deliver great products
that delight those who are the most important in your world:
your customers.
abouT The auThor
Mark Lawler has been working in the computer industry for
more than 20 years, focusing on the successful development of
commercial software applications. He has been directly involved with
and a strong driving force behind many well-known commercially
successful products and companies. His goal is to provide the very
best in executive managerial and technical leadership, empowering
managers and teams to deliver great products that are on time,
delight customers and bankrupt competitors. He can be reached at
mark.lawler@comcast.net.
PM

16 pragmaticmarketing.com SUMMER 2014
M
arketing has changed more in the last five to seven years
than at any other time during my career. The pace of
change has quickened, there is more direct pressure
for marketing to demonstrate its contribution to the bottom line,
many more channels of communication are available to reach
increasingly fragmented audiences, and all of this must be done
with scarce and expensive talent and resources.
Despite all this change, many of the core processes of
marketing remain unchanged. We still spend time writing thick
marketing plans, constructing yearly budgets, launching big-bang
ad campaigns and targeting broad audiences (instead of having
conversations with people).
Some marketers, including myself, are taking a different
approach—one based on agile development. Software developers
faced a similar crisis in 2001. They were pressured to get more
done with scarce resources, and to adapt rapidly to change. They
responded with a set of principles and a methodology called agile
development, and it has transformed software programming.
I believe that we can apply many of the same principles and
methods to marketing and transform our discipline.
What Is agIle MarketIng?
Agile marketing is an iterative and experimental approach to
marketing that values adaptability and responsiveness to change
over long-term planning. It also values individuals and two-way
marketing interactions, as well as collaboration among
the various marketing disciplines. There are six core values of
agile marketing.
Responding to change over following a plan. It’s not that
agile marketers don’t do any planning; they do. However,
marketers should take a cue from software
development to become more adaptable. by jim ewel
why
market ng
should go agile

SUMMER 2014 pragmaticmarketing.com 17
2-4
weeks
24
hours
SCRUM PROCESS
Daily Scrum
Marketing
Backlog
Sprint Planning
Session
Sprint Sprint Review
& Retrospective
Results
they put a premium on adapting and responding to the
marketplace through constant adjustments to their plans
and priorities on a weekly or biweekly basis—rather than
an annual or semiannual planning cycle.
Rapid iterations over big-bang campaigns. Few
marketing campaigns can get it exactly right the first
time, and there is also value in speed to market. Agile
marketing recognizes this and values an iterative approach.
It encourages marketers to try something out quickly
and fine-tune it as they go, rather than putting all of their
energies and dollars behind a big-bang campaign.
Testing and data over opinions. If you’re iterating,
how do you know something is working or not working?
Data makes the difference.
Individuals and interactions over one-size-fits-all.
Agile marketers realize that there isn’t just a market
for a product, but many individuals who make individual
buying decisions. Buyers make their decisions as the
result of conversations, not through traditional one-
way advertising. Agile marketers seek to foster those
conversations, and provide an individualized buying
experience. Think of how Amazon customizes its
recommendations to your unique purchase history;
this is an example of individuals and interactions.
Collaboration over silos and hierarchy. In this era
of specialization, it is tempting to organize marketing
departments around skill sets: PR, advertising, social media,
etc. But to the buyer, the product or the company is the
product or the company, regardless of the medium used
for communication. Collaboration is necessary to ensure
not only consistency of message, but also a user
experience that is consistent and pleasing. Teams that
collaborate also get more done.
Agile marketing is a mindset: Marketers who
practice agile marketing put the customer experience
at the center of everything they do. They focus on
solving buyer problems and the buyer’s journey, not
on selling and the sales cycle.
Lastly, agile marketing is about aligning
marketing with the business and sales goals of
the organization, getting stuff done quickly and
documenting the results with transparency
and accountability.
Planning for Change
How do you “plan for change”? How do you organize
your marketing team to respond to new demands when
you don’t know what those demands might be, or how
you’ll address them?
The first step is to admit that your priorities will be in
a state of constant change and to throw out those tools that
give a false sense of security about the amount of control
you have over that change. Throw out yearly marketing
plans, yearly marketing budgets and rigid organizational
charts. Instead, revise your priorities, including how you
spend both your time and your budget, on a regular,
frequent schedule: at least once per month, and if you’re
really ambitious, once every two weeks.
Second, make it someone’s job to rapidly respond to
changes and opportunities in the market. Depending on the
size of your organization, create a team, assign a person or
make it 50 percent of someone’s job to respond in real time
(somewhere less than 24 hours, perhaps less than 4 hours)
to particular kinds of opportunities such as competitive
threats, newsjacking and brand-damaging events.
SCrum
Scrum is a formal methodology that can help you revise
your priorities. Agile marketers use it to manage their
work, just as agile development teams use scrum to
manage software development. It’s beyond the scope of
this article to cover everything you need to know about
scrum, and many of the readers of Pragmatic Marketer are
very familiar with both agile and scrum. Instead, let
me outline the basics of scrum, and discuss how scrum
for marketing is somewhat different than scrum for
software development.
Scrum starts with the marketing backlog, which
is basically the list of all the potential activities that
marketing could do. The marketing backlog can be seen
as the “wish list,” although it should be cleaned up and
prioritized over time.
Unlike scrum for agile software development, most
marketers do not write user stories. Instead, they break

tasks down into manageable chunks
that are typically half a day to 1
week in size, describing what’s to be
done, who the audience is, what the
desired outcome is and how success
will be measured.
At the sprint planning session,
the marketing team meets with
executive management and sales for 30-60 minutes to hear
about the current business and sales priorities, adding any new
items that come up into the marketing backlog. The team then
prioritizes work off the marketing backlog, accepting enough
work to fill the length of the sprint (usually 2-4 weeks of work).
Although scrum as practiced by developers requires
assigning each item story points (a measure of the complexity
of the task), I find that marketing teams tend to keep it simple,
deciding for each task whether it is a half-day, full-day, half-week
or full-week task. Anything that is bigger or longer than a week’s
worth of work should be broken down into smaller tasks.
Once the team has 2-4 weeks’ worth of prioritized activities,
they go to work. This 2-4 week period of getting things done is
known as the sprint.
One of the most important rituals of scrum is known as the
daily standup. Every day, or at least 3 times per week, the team
meets for no more than 15 minutes. Each person on the team
answers three questions:
• What work did I complete yesterday?
• What am I working on today?
• What issues, if any, are blocking me and preventing
me from moving forward?
When the sprint is finished, the sprint review is held.
Executive management and sales are invited, and the marketing
team reviews the results of the sprint. For software developers,
the sprint review is a time to demo working software. For
marketers, new marketing materials are handed out or shown,
new websites are demonstrated and the results of any mini-
campaigns are shared. The sprint review provides a degree
of accountability and transparency that is sometimes lacking
in marketing. It answers the question, “What do you guys in
marketing do anyway?”
The sprint retrospective is a short internal meeting of the
marketing team to talk about what worked and what didn’t work
during the last sprint. It allows for adjustments to the process
and methodologies used by the team over time.
Who Is PractIcIng agIle MarketIng?
Jascha Kaykas-Wolff is one of the early adopters of agile
marketing. He has used the methodology at companies as diverse
as Webtrends, Involver, MindJet and his current company,
BitTorrents, where he is chief marketing officer. You can read
some of his posts on agile marketing at marketingiteration.com.
Jascha credits agile marketing with helping him to create an
agile culture:
Agile processes and tools are actually install mechanisms for
culture. By requesting people to work together in certain ways, track
specific metrics and check in with each other at specified intervals,
companies can put in place the building blocks for people to interact in
positive, productive ways.
EMC is also an early adopter of agile marketing. You can
read about their success with agile marketing at Scott Brinker’s
Chief Marketing Technologist blog, www.chiefmartec.com as
well as watch a video of David Quinn, EMC’s senior director of
corporate marketing, presenting to the Agile Marketing Meetup
group in Boston on YouTube.
Quinn credits agile marketing with changing how EMC
launches new products and interacts with the business groups. It
not only has helped the marketing team with time management
(and eliminated those long “coordination” meetings), but also
provided greater accountability and transparency.
Lastly, I should mention Frank Days, whose blog
Tangyslice.com has been a source of inspiration for me. He has
implemented agile marketing at Novell and Correlsense, and his
approach to agile marketing is refreshingly pragmatic. He likes
agile marketing because it helps him get better results, plain
and simple.
about the author
Jim Ewel is a startup CEO and blogger on the topic of agile marketing.
He is currently the CEO of InDemand Interpreting, which provides
language-interpreting services to hospitals, clinics and physician
practices nationwide. Previously, he was the CEO of Adometry
and GoAhead Software. Earlier in his career, he was a VP of server
marketing at Microsoft. You can read more about agile marketing at his
blog, AgileMarketing.net.
PM
The sprinT review
provides a degree of
accounTabiliTy and
Transparency ThaT is
someTimes lacking in
markeTing.

A step-by-step guide:
Cut out framework, avoiding pesky paper cuts.
Post conspicuously throughout office.
Follow framework faithfully with peers.
Reap the benefits of being market driven.
Rinse and repeat.
© 1993-2013 Pragmatic Marketing, Inc.
Strategy
execution
Visit pragmaticmarketing.com/framework or call 480.515.1411 to learn
more about how to put the Pragmatic Marketing Framework™ to work for you.
5
4
3
2
1

O
ver the years, I’ve had the prIvIlege of
working with product and development
professionals from around the globe.
All have been highly motivated to succeed—
and to have their company be successful and
profitable. However, there is a critical juncture
in every product-development process where
many stumble: the handoff of the requirements
to the development team. Here are seven tips to
help make your next project more successful.
1. Build a Business Plan and KeeP it uP to date
As companies move to new development
methods, they often feel that a detailed business
plan is no longer necessary or as important.
But “we’ll be done when we’re done” will not
usually pass muster with leadership or get the funding your
project requires. Yes, you should encourage flexibility to roll
out products without constraining creativity. But you need to
articulate the business goals of every project based on some
initial expectations (date, cost, revenue, etc.).
Be mindful that priorities and market conditions will
change mid-project, budgets will get cut, key people may
leave the project and development may over- or under-
commit. The initial business plan will justify
the investment at the start of the project.
However, you should also keep it updated
throughout the project, including the
latest internal and external changes,
and communicate the business impacts
to management.
There are cases where the project no
longer makes business sense to complete. For
example, if you missed the market window or
the competition just made the entire project
irrelevant. If you don’t have an up-to-date
business plan, how do you make that call?
2. Give desiGners What they need: Context
aBout the MarKet
To do their jobs and apply their innovative talents, designers
need context around the description of the problem. When
shifting from a traditional requirements approach (“The
product shall …”) to a market- or user-based approach, many
think that requirements are supposed to be written at a
very high level. “The network operator has a problem if the
network is overloaded.” But how does he get notified or want
to be notified? How quickly does he need to be notified? Why
By John MIlBurn
for hIghly successful
requIreMents ManageMent7 tIps
escape
the legacy
of blame
that often
happens with
requirements.

SUMMER 2014 pragmaticmarketing.com 21
does he need to be notified? What does it mean that
the “network is overloaded”? Why does he care? How often
does this occur? It’s not about writing requirements at a
higher level; it’s about providing more context about
the problem. Then the designer can own defining high-
performing, well-architected solutions that provide a pleasing
customer experience.
3. RemembeR that Development Is the CustomeR foR RequIRements
I once worked with a company that was debating whether
their market requirements document (MRD) was to be
written in Word or PowerPoint. I asked them, “How does
development want to receive it?” Their answer: “We haven’t
asked.” A requirement, or a group of them delivered as an
MRD, is intended to build a bridge for communicating with
your development team. They are the customer for the artifact.
How do they want to receive them? In what syntax? What
tools will they use? The product team owns the overall success
of the product in the market, but the development team
provides the technology solution to make that happen. Provide
context, problems to solve and the acceptance criteria in the
way that they can best receive and use them.
4. DelIveR RequIRements In an IteRatIve fashIon;
Don’t just thRow oveR the wall
Continually communicate the requirements with the team
that will be defining and delivering the product. Don’t
assume that the development team will read and understand a
requirements document or list. Though this takes time, it will
save huge effort in the long run. There are so many variables
involved that product management must provide a forum for
all to discuss them. What about this? And that? Who? How
often? Why is this higher priority? What if we don’t do this
one? Do you really mean that? What about all of our technical
debt? These discussions need to be had at the beginning and
throughout the project. Having the right people hashing
through the detailed requirements, posing and discussing
questions and getting a common understanding of the problems
will not only encourage better teaming, but also allow you to
deliver more innovative products in a shorter amount of time.
5. wRIte as Content, not syntax
A regular syntax today for requirements is the user story
format. This has become very popular with the movement
to iterative (Agile, Scrum, XP, etc.) development techniques.
Generally, user stories come in the following form: “As a
role, I want to do something, so that I can accomplish a goal
or objective.” In many cases, the user story syntax may be
used to express a market-based requirement. But just because
the requirement is written using the
syntax doesn’t mean it’s a well-written requirement. “As a lab
technician, I want to have a red ‘trouble’ button on my screen,
so that I can do my job” is a poorly written requirement—yet it
conforms to the user story syntax.
6. foCus on what, not how
Requirements are “market requirements” not “product
requirements.” The product team’s primary responsibility
with development is to provide problems to be solved in the
market—not product specifications. Too often, either out of
ignorance or the desire to impose one’s technical opinion,
requirements are written that prescribe how to build the
product and not what the market problem is. For every
requirement, ask yourself: Have I stepped over the line and
given development a how instead of a what?
7. have some fun anD make It a team spoRt
Lastly, defining and delivering products is what technology
companies do. It should not be drudgery or viewed as a battle
between the product team and development. Encourage some
creativity in the process and have a little fun.
Just because companies have done away with sponsored
beer blasts doesn’t mean we can’t go to a park or bar and have
a weekly group happy hour. Give out awards for the most
creative solutions to gnarly problems. Celebrate a release with
music and cake.
Incorporate these seven tips in your next and all future
projects, and you will find that your projects will run much
more smoothly and deliver better outcomes overall.
about the authoR
John Milburn is a Pragmatic Marketing instructor who has “walked
the walk” in technology product management. Throughout his 20+
year career, he has managed or delivered more than 40 hardware
and software products and implemented the Pragmatic Marketing
Framework at many companies. John has served on the planning
team for Austin ProductCamp and helps groups around the United
States create and run their own ProductCamps. He can be reached at
jmilburn@pragmaticmarketing.com.
Requirements
are “market
requirements”
not “product
requirements.”
PM

How a Tech Background
Empowers Product Professionals
Technological knowledge isn’t a
requirement, but it is beneficial.
Build Better Products
How a Tech Background Empowers
Product Professionals 22
Confessions of a Nontechnical
Product Manger 24
departments
sell more stuff
Engage Your Audience
with Google Hangouts 26
Take the Guesswork Out
of Content Creation 28
Lead strategically
Speaking the
Same Language 32
Four Power Cues
for Leaders 34
I
’ve been asked repeatedly over the last decade if having
a technical background is required to be successful as a
product manager. The answer is no. But it has certainly
helped me to be more effective. This is a personal and
situational question which has no crisp answer—but sharing
some of my experiences may help you to work more effectively
with, or as, a product manager with a technical background.
Internal Wiring
I don’t know if I went to school for engineering because of how
my brain was wired, or if Carnegie Mellon rewired my brain
for me—but I always say it is where I “learned how to learn.”
How I approach learning, and how I apply different analytical
techniques to synthesis, situational analysis and development
of insights is driven by how my brain is wired. In product-
management speak, the way I learn things is a distinctive
competence, and it makes me objectively better as a product
manager. I would argue that this is because of my technical
background. I would expect people with similar backgrounds to
have similar advantages.
The Inside Track
I tend to work most frequently with businesses that incorporate
software development into developing solutions for their
customers. I happen to have also spent several years developing
software—and eventually leading teams which were developing
software. This arcane knowledge of the secret handshake has
helped me develop effective working relationships with the
team members who are actually creating the product. When you
do something, you learn it more viscerally than if you only
read about it. Building on this deeper level of insight, which only
comes from doing, is one way to develop camaraderie with the
team of people creating your product.
The Temporary Crutch
In terms of what you already know, a technical background
only helps for a short while. Eventually, the information
you acquired will become irrelevant—and eventually it
will mislead. Imagine trying to apply pre-SQL database
perspectives to conversations about NoSQL and
distributed data storage architectures and the
ensuing release-planning activities. You
can also, of course, have a bundle
of technical knowledge,
which is not relevant to
your problem domain.
Bernoulli’s equation is
not going to help me
increase conversion
rates on a website, or
help me assess the
value of continuous
integration.
My approach to
applying the things
I already know—or
used to know—is
to leverage that
knowledge for
By SCoTT SehlhorST

shared context in conversation, pattern recognition when
being exposed to new-to-me information and generally
applying the principles of learning to whatever is in front of
me. I do not try to apply the knowledge to solutioning, beyond
using it to guide some directed questioning or to help with
hypothesis formulation.
One of the phrases I remember from Pragmatic Marketing’s
training was a question from my instructor: “If you are going to
do their job, who is going to do your job?” That very question
helps me walk away when I start to get too far down into the
weeds in discussing how we’re going to solve the problems. It
is a slippery slope, especially when you really enjoy technology
and secretly wish you could be coding away (or designing or
testing) with the rest of the team.
Helpful, with a Twist
The crux of it is that the benefit of having a technical
background does not come from participating in the technical
work, but from how it helps you collaborate with the technical
team. Collaboration is a soft skill, and it is the one that is broadly
helped by having technical wiring.
Sometimes, we work on products that are helping our
customers to solve problems in a technical domain. In these
cases, being technical can help quite a bit—and may even
be genuinely required—in developing an understanding of
your market.
Consider, for example, developing the staffing schedule for
a large hospital. You need to be able to synthesize technical
problems, combining the abstract mathematical problem
(the nurse-rostering problem is a classic computational
conundrum) with the business
appreciation for defining the
“good enough” solution. In my
opinion, developing insights
about how to compete in this
market requires you to be
able to appreciate the mathematical complexity of the
value proposition, so that you neither assume it is trivial nor
intractable. This is a problem that people will pay to solve. It is
also a problem that requires a combination of technical solution
and business perspective.
At the end of the day, if you’re developing a product that
is addressing a particularly technical problem, I don’t believe
you can be effective without sufficient “technical wiring” in
your brain to be able to fully appreciate the challenges (and
opportunities) in play. One of the better (and very technical)
product managers I have worked with happens to have a degree
in history, but his brain was absolutely wired to be able to
think technically. Demonstrated success in a technical role (or
education) is a likely indicator, but an imperfect filter.
In a Nutshell
Having an existing body of technical knowledge in your head is
of limited and suspect utility. Limited because it is more useful
in application than in collaboration, and suspect because it will
become irrelevant or even wrong faster than you will expect. I
think of this as a circumstantial outcome of having a technical
background—not an asset that can be directly leveraged.
But even when you’re creating products that are not
“technical,” having a technical perspective can help you
significantly in the process of creating those products. And that’s
not because it helps you do any of the technical heavy lifting,
but because it helps you work more effectively with the people
who are doing the technical work.
About the Author
Scott Sehlhorst has been helping companies achieve software product
success since 1997, and started Tyner Blain in 2005. He is a product
management and strategy consultant, and a visiting lecturer for the
Dublin Institute of Technology’s Product Management program. Scott
has managed teams from 5 to 50, and delivered millions of dollars in
value to his customers. You can reach him at scott@tynerblain.com, or
join in the conversation on the Tyner Blain blog.
PM

Confessions
of a Nontechnical
Product Manager
Tips for turning a nontechnical background
into a winning opportunity
By Julie BaBB
M
y friend Matt was helping a client adopt a more Agile software product
development process. His first question to me was: “How do we test a product
manager applicant’s computer science chops?” To which I replied, “Who says
your PM has to code?”
As a “nontechnical” product manager and entrepreneur who has overseen the
development of many projects from mobile games to multiplatform
marketing campaigns, I get variations on this question a lot. Some employers
and clients fear that product professionals who don’t code won’t be able to
communicate properly with their development team.
Of course, every project is different but the two roles require very
different skill sets. Personally, my lack of formal computer science training
has never held me back, and can often be an asset. Here’s six tips for current
and aspiring product professionals who don’t code:
1. The Product is the Boss
A good product professional is a leader, but is not a boss. The product
is the boss. Now here comes the corny business-book truism: Your top
priority at work is to make your boss look good. Your job in a product
role is not to bark orders at designers and developers, nor is it to be
subservient to them. Rather, you are there to communicate effectively
with the entire team including executives, marketers and salespeople, to
make sure the product is great. A truly great product professional keeps
the team focused on that common goal and helps determine the best
path to get there.
2. Tell a Great Story
In user-focused design and development, we can think of each feature as a
“story.” When we describe each development task, we are essentially writing a
story that will lay out the scenarios and requirements that allow the developer
collabora
NO CODEREQUIRED
story
teller
listene
non-
technical
PRIORITY
HANDLEWITH CARE

PM
to dive in and formulate a solution. It’s important to remember
that although we must define success, we don’t need to know
the exact path to get there. In fact, good story writing is not
technical at all. It is a unique language that bridges user
needs with desired outcome; developing this skill requires
empathy, attention to detail and systematic thinking. Tell your
team a great story and they will come back with the technical
requirements and functions that bring it to life.
3. Be Available
Writing a good story is an important first step, but your
job doesn’t end there. You are an integral member of the
team, and you must be available to facilitate, translate and
communicate. Need a better feature description? Rewrite it
and make sure everybody is on board. Having a communication
problem with a team member? Fix it ASAP. Don’t hide behind
Gannt charts or shift the blame when challenges arise. Tackle
things head on with your team, and listen to them.
4. Ask Questions
I’ve never worked with a developer who wasn’t able to
easily diagram a stack for me or describe how an important
subsystem works. Most of the time, developers are excited
to share their knowledge. You just have to ask. This
understanding is an advantage that product professionals
with a computer science background bring to the
table, but it’s a skill that a nontechnical PM can
easily develop. The more of this knowledge
you accumulate, the better you’ll be at
predicting how long things will take—and
this will help you and your management
team prioritize. In the meantime, you
have options. Bring a developer into
planning meetings to contribute, or
avoid committing to timelines without
consulting the team.
If you walk away from a technical
conversation a bit confused, jot down the
bits you understood and the things you didn’t
and research it on your own later. It’s probably
not imperative that you understand a complex
development system now, but a better understanding
may help inform a conversation or decision in
the future.
5. Speak Up!
You may not know the ins and outs of C++ or
how to whip up a web app in a couple of hours
using Ruby on Rails, but don’t underestimate the
value of your own experience and common sense. Even the
best developers need help sometimes. And a good product
professional can be a trusted collaborator to bounce ideas
off of.
When a developer asks me to help with a technical
problem, I start by discussing the feature from the user’s
perspective. Then I transition to the developer’s point of
view. Is the basic logic sound or are there holes in it? Is there
a more simple way to get the same results? Is it built on,
pulling from or sending out to other parts of the application?
You’d be surprised how valuable your new perspective can
be. Sometimes just identifying the trade-offs with technical
decisions can help your developer choose a direction to best
move forward. Code isn’t the only language developers know.
Every feature is a series of rules that follow a system of logic
that can be discussed in plain old English—or in diagrams,
visuals and even emoticons if your coder doesn’t speak English
(which I’ve also experienced).
6. Listen
Just as you may be able to inspire a coding solution for your
developer, every team member can inspire product solutions.
Encourage the entire team to volunteer feature ideas, share
cool new capabilities, voice insights from data that may have
been missed and find easy wins.
Being a good listener and making sure everybody is
comfortable sharing their ideas will ultimately be a huge
benefit to the product. And you definitely don’t need technical
training for this skill—which may be the most important one.
About the Author
Julie Babb is a product manager at Pivotal Labs, the agile development
services unit of Pivotal. She works with clients to wrangle digital teams,
obsess over process and create momentum. She also shares insights
on making things for partners like Game Developers Conference, New
York University’s Interactive Telecommunications Program and Tribeca
Film Festival. She can be reached via Twitter @awkward_hug.
learnmore
Learn More!
Want to Build Better Products?
Attend Pragmatic Marketing’s Focus and
Build courses, where we’ll teach you how to
identify the right product strategies, as well
as how to create and prioritize requirements
based on market facts.
Visit www.pragmaticmarketing.com/courses or
call 480-515-1411 for more information.
ator
er

A
s described by GooGle, Hangouts are a unification
of video, voice and chat. But there can
also be a psychological impact to your
audience: the humanization of your brand through
authentic conversations.
Authentic conversations really began with
blogging several years ago. From there, we went to
teleseminars where you could actually hear people’s
voices, followed by the combination of voice and visual
that webinars offered. Now video marketing is big, but has
gotten so elaborate with intros, outros and jump cuts that
they seem less authentic. They have basically broadened the
empathy gap—and Hangouts can help you close that gap
with your audiences.
During one Hangout that I hosted, a backdrop fell on
my head—and I actually got hired by a big client right after
it. There are no guarantees that things won’t go wrong in
Hangouts, but that’s the beauty of them. It allows you to be
more real and more connected with your audience.
Don’t treat Hangouts like a webinar replacement and rely
on slides. Use the opportunity to actually hang out with your
people, engage with them, have a good time, answer questions
and give value. And if the value is good, people will buy your
product or service.
There are many other benefits of Hangouts as a
platform too:
• They are free, regardless of the number of viewers.
• They are multipurpose, allowing you to build authority
and engagement with regularly scheduled web shows,
product announcements, one-on-one video conferencing
and panels.
• They are multifaceted, streaming live to your YouTube
channel, linking to your Google+ page and offering
embed codes that you can use on a Facebook tab,
website or blog post.
• They have long shelf lives. When the broadcast is finished,
the video is available within minutes in your YouTube video
manager for you to edit as you like.
• They outrank other content in searches, because videos
rank higher—but they will also outrank a standard
YouTube video because Google ranks on what is current
and relevant.
Getting Started
I’m a firm believer in driving everything to your website, rather
than sending people to your Google+ and YouTube page. Your
content will be available at those other locations for people to
come across. But if we’re actually sending people in all those
directions, they won’t know where to engage with you. It gets
confusing, and we all know that the confused mind never
buys. Sending everyone to one location also improves search
rankings and is easier to manage.
I have a threefold process for setting up Hangouts that are
embedded on my website:
1. Send teasers using my website domain and a “watchlive”
extension followed by a number of the episode (for
example, www.hangoutsforbusiness.com/watchlive-2).
2. Add the embed link Google Hangouts provides after
hitting “Broadcast Now” to the website.
Sell More Stuff
Engage Your
Audience with
Google Hangouts
By Brandee SweeSy

3. Include a commenting system to enable interaction.
I use a Facebook plug-in, because everyone knows
how to interact with it.
Once you are up and running, remember
that Hangouts are about the humanization of
your brand, engaging with your audience and
providing value. Here are some best practices
to ensure both you and your audience get
that value:
Practice makes perfect. Hangouts are
not entirely intuitive, so get in there and play
around. You can always delete the video.
Customize. The Hangout Toolbox
allows you to brand your Hangouts with
custom overlays. I include my hashtag
and my trademark. You can also include
pattern interrupts (a pop-up slide), such
as “brought to you by” if you have a
sponsor or “go buy my stuff here” to
inspire people to take action. I usually do
five or six of those.
Remember to engage. I let my audience
know they can start posting any questions they
might have right at the beginning, and it doesn’t
have to be driven by what I’m saying. (There’s
actually a 45 second to one-minute delay between
what you’re saying and what your audience is hearing,
and I also inform them of that.) People love to be included in
a Hangout, and I say their first name and actually read their
questions out loud before answering.
It’s in the name. Be aware of how you name your Hangout,
because your audience can come across your Hangout several
different ways. Something like “Episode 37” won’t make sense
without context. You want to title it so they know what to expect
and then include branding.
Don’t get discouraged by smaller live audiences. A big
thing to remember, since we are so programmed for instant
gratification, is not to be discouraged if you only have three live
viewers. I know of one Hangout that had 400 live viewers, but
then had 40,000 views within four days. So keep on pumping
out that content.
Make the most of marketing. I love the humanization of
the brand and the live interaction that Hangouts provide, but
it’s also what I call “marketing on nitrous.” It’s basically rocket
fuel for your brand because they are easy to promote and there
are many ways to repurpose the content afterward to continue
to spread the word.
Start promoting your live event four days in advance. I send
them to a landing page, capturing their first name and email
before sending them to the “watchlive” page. I keep promoting
over the next few days through my other channels, and do one
last promotional push on Facebook five minutes before the
Hangout starts.
After the Hangout, it’s really important not to just end
the broadcast and call it done. Optimize the YouTube video
afterward, using keywords to tag it and include in your title and
descriptions. (Another tip: Identify the keywords before your
Hangout, and mention them several times to get search credit
for closed captioning and transcriptions of the video.) Also,
include calls to action above the “show more.”
Take the content and repurpose it like crazy. I take two
compelling minutes out of the video, sometimes adding an
intro and outro, and promote it separately with an external
annotation taking them to the longer version. (If my Hangout
is on the longer side, 30 minutes to an hour, I’d pop out four
or five of those to get traction on YouTube.) You can also
transcribe the video and make it a blog post, strip the visual
portion and make it a podcast.
If you are strategic with your optimization, you can skyrocket
to the first page of Google searches on a topic. So Hangouts
not only portray your brand in a very human light with your
current audience, they give you the opportunity to spread that
light over new audiences.
About the Author
Brandee Sweesy has been dubbed the “Hangout Marketing Expert”
by some of the top names in the industry. Her passion and 20 years
of experience in marketing, branding, strategy and most of all
engagement with communities has led her to help people
with live video and Google Hangouts. She can be reached at
Brandee@BrandeeSweesy.com.
1 A Google+ account with at least a profile picture,
since that picture will show on your screen if your
camera stops working
2 A linked YouTube channel that has been verified
(otherwise it can’t allow uploads that are longer
than 15 minutes)
3 Webcam (many people just use their laptop camera)
4 Headset (to avoid feedback)
5 Hard wiring (versus over Wi-Fi) for improved quality
6 Good lighting
7 Google Chrome browser, since Google tends to play
better with Google
PM
a few things you’ll need to get started with hangouts:

Take the Guesswork Out
of Content Creation
A content standards guide is the key to optimal content.
T
here’s no doubt about it, we’re
in a content race. And compared
to B2C businesses—the original
content pushers—B2B organizations
are struggling to keep up. In particular,
technology companies are realizing the
need to stand out in a commoditized
industry where churning out high-quality
content is a daily challenge.
While the quantity of content a
marketer produces can boost traffic, they
sometimes forget that quality is equally
important. And in an environment where
prospects are bombarded with messages,
they also need to hit the mark with every
piece of content they create.
This is no easy task. B2B companies
still cite the top three content marketing
challenges as lack of time (69 percent),
producing enough content (55 percent)
and producing the kind of content that
engages (47 percent), according to
research from the Content Marketing
Institute and MarketingProfs.
With so much time and resources
needed to meet the demand, can
technology marketers reduce their
content-generation time and still maintain
their market position?
Enter the content standards guide,
a stylebook that ensures consistency
across your content. Whether you’re
launching new products, redesigning
web pages, promoting your proprietary
solution or revamping your newsletter, a
content standards guide is a key element
to producing high-quality and relevant
content faster.
Its benefits are twofold:
1. As a reference guide for internal
and external writers, it helps keep your
messaging, tone and voice consistent
across all media. When these elements
are aligned, marketers can produce
content faster because they know exactly
how to address their audience. With clear
standards, they eliminate doubt and
create content with greater efficiency.
2. A content standards guide
encourages leakage at the top of
the funnel. Why is this a good thing?
Speaking in a consistent tone and with
consistent keywords and terminology
helps eliminate unsuitable prospects
from your funnel and retain those who
are a perfect fit. It leaves no room for
misinterpretation of who you are as
an organization, what you do and for
whom. When you speak to prospects in a
consistent manner, you constantly restate
your value proposition and retain your
market position.
A content standards guide is a living,
breathing document that is updated as
your business changes. Its benefits go
well beyond time savings and positioning
By Sandra Jean-LouiS
Sell More Stuff

Learn More!
Want to Sell More Stuff?
Pragmatic Marketing’s Market and Launch courses
show you how to align your marketing strategy
with the goals of your whole organization, as
well as how to execute successful product and
marketing launches that deliver results.
Visit www.pragmaticmarketing.com/courses or
call 480-515-1411 for more information.
support. A well-defined guide can:
• Protect your brand and messaging
• Bring consistency to blog posts, articles, case studies,
white papers and all marketing collateral
• Cut onboarding time for new employees, including writers
or marketing staff
• Set standards internally for delivering consistent messaging
to prospects and customers
• Set your organization apart in a commoditized
link-building world
A content standards guide is more than a repository of
standard verbiage and mission statements. It’s how you present
your content to the world. It encapsulates what you stand for in
a readable, friendly and non-corporate-speak format.
Create Your Guide
It takes some effort, but you can capture the essence of your
organization in a single document.
You’ll want to start by assigning a writer who can steer,
manage and track the project—then set a timeline and stick to
your deadline.
Next, bring sales, marketing, customer service, PR and your
web team into the discussion. Anyone who actively deals with
customers can offer valuable insight. Get them involved and
enthusiastic about the process by bringing everyone together—
either in one big session or a series of smaller ones—to cover
the following:
• Outline what you do, for whom and how.
• Describe the personality or brand of your company.
• Define your unique selling proposition (USP) or value
proposition.
• Describe your buyer personas, demographics and
firmographics. What are their concerns, needs and
interests? What keeps them up at night, and how do your
solutions help them?
• Who’s the competition? List your top two to four major
competitors and how they excel.
• What do you do better than the competition?
• Include any brand conventions currently in use and
standard translations for your tagline, brand names,
category names, etc.
• Include search-engine optimization (SEO) guidelines: What
keywords does your target audience use to find you?
Many businesses fail to integrate their value proposition
into their content. This means they miss countless opportunities
to connect and engage prospects. Tying your proposition and
buyer personas into your guide will help its users stay focused as
they craft new messages. And with all the elements listed in one
document, it will streamline overall efforts and produce laser-
focused content that speaks directly to your ideal prospect.
You can also create standards for landing pages, services
pages, product pages and blog posts. And don’t forget to
jazz things up with slides, screenshots and hyperlinks to help
illustrate a point.
Once you’ve finalized your guide, distribute it throughout
the entire organization and start planting the seeds to better,
faster content.
Apply Your New Guide
Start with your website and look for SEO revision opportunities.
Describe the purpose of your website: Is it to capture leads via a
sign-up offer? To get prospects to call your toll-free hotline? To
get them to directly contact a sales executive?
Are your calls to action in the same vein? Do your products
or solutions use consistent naming conventions across the site?
Do you call someone a sales executive on your home page and
a sales rep three clicks later?
Once you’ve revised your website, start applying the
standards to new content, social media posts, newsletters
and marketing collateral. Over time, your fresh, consistent
messages will attract search engines and improve your content
performance.
By keeping standards and aligning your messages, you’ll
substantially decrease the amount of time it takes to create
high-quality and relevant content. What’s more, your content
will rise above that of your competitors, as it will appeal to your
prospects’ interests and help keep your organization top of mind.
A content standards guide is your arsenal for better, faster
and focused content generation. And the more focused you are,
the more revenue you’ll drive.
About the Author
Sandra Jean-Louis is a B2B and Certified SEO Copywriter at Word
Central. She’s a seasoned online marketer who helps information
technology, software and professional service firms generate more leads
and sales with targeted content and marketing copy. Connect with
Sandra on LinkedIn or contact her at Sandra@WordCentral.ca.
PM

Market launch price
Pragmatic Marketing now offers six different certification levels
that allow you to demonstrate your understanding of the Pragmatic Marketing
Framework™ and the activities and skillsets required to bring it to life.
Each certification coincides with one of our courses, and you have
the opportunity to sit for the exam at the end of each training day.
So if you’re ready to demonstrate to the world your expertise,
visit pragmaticmarketing.com/certification
or call 480.515.1411.

G
rowth and market demand for products and
services is a positive experience at any
company, but it can also lead to challenges in
maintaining consistent practices and making informed
decisions. At Sabre Airline Solutions, we provide enterprise
software and services for the airline industry. Over the
years, we’ve grown our portfolio of products with in-house
development, acquisitions and strategic partnerships.
Given this growth, thinking about how we continue to
invest and operate became more important.
When I came to work here in January 2012 as
chief marketing officer, one of the first assessments
I conducted was a gap analysis relative to the
Pragmatic Marketing Framework. I have experience
in both small start-ups and enterprise software companies,
and this is the only way I knew how to operate. I walked my
management team box by box through the framework, and
we collectively agreed on our areas of weakness. This formed
the basis for targeted initiatives that solve for these gaps and
serve as foundational elements as we begin to manage our
business differently.
In 2013, we decided to have Pragmatic Marketing’s
Executive Briefing onsite with a broad cross-executive
leadership team. Leadership buy-in and alignment is critical toward
transforming a business. We’ve since followed that up with three sessions
of the Foundations and Focus courses, each with about 60 to 70 attendees
from the product management and marketing organization. The goal was
to ensure the team was on the same page as it related to best practices,
and to have a framework and tools to leverage. The training, in conjunction
with implementation of standard product life-cycle management practices,
was the basis for evolving to a market-driven organization.
Defining Roles
With the training, we were able to bring clarity relative to the strategic and tactical
parts of the Pragmatic Marketing Framework. This included product management,
Lead Strategically
Speaking the Same Language
By Dana Jones
How Sabre Airline Solutions is leveraging Pragmatic Marketing
best practices to transform and scale its business

product marketing, marketing communications and our interactions with
technology and sales. This clarity meant everyone could focus on the jobs that
needed to be done for their roles. Like all businesses, we have to manage
through resource constraints—so while it’s not perfect, we are making progress.
Focusing on the Building Blocks
How we were producing solution strategies and business cases was not
comprehensive or consistent. And where we spent our investment dollars was
based on historical trends versus long-term strategies.
If you think about a product manager running his own
business, long-term views of the market problems,
the competitive landscape, investment and ROI,
and target customers are a few key components to
consider. Pragmatic Marketing gave us tools
to put portfolio management disciplines in
place and make optimized decisions based
on clear strategies and business cases.
We also identified a gap in our ability to
enable our field force through positioning
and messaging documentation. We weren’t
arming them to have strategic customer
conversations and show up as thought leaders.
We are now working through a comprehensive
sales-enablement program, including training and
certification, self-study materials and key sales tools,
such as customer testimonials and solution demos.
To arm a global sales force will take time, but we
are making huge strides.
Pricing is another key area that needed
attention. Solution owners or the field team
weren’t armed with the right tools to make
strategic pricing decisions. We needed to
institute value-based pricing practices. This
includes an understanding of market dynamics
to set list pricing, governance councils and
packaging. A lot of work commenced last year to
establish this discipline.
Another example of our improvement since
taking the courses is our roadmaps. We’ve become
much more disciplined in what they should look like
and have implemented that across our portfolio. Now every
area uses a consistent roadmap template—something we didn’t have
before. More importantly, they are tied to long-term solution strategies and
investment decisions. We have a quarterly cadence on roadmap approvals
and will begin to proactively share the content
of the roadmaps with the field-facing teams.
The goal is to communicate key changes and
business rationale since the prior quarter and
help them have strategic customer conversations.
Roadmaps are also a key input into the
development process. This process, along with
artifacts like a release scope document, is helping
us manage and measure our releases relative to
schedule, scope and quality.
Shaking up the Culture
All of these examples are driving a culture shift
from a behavioral perspective. People are asking
different questions and being more proactive,
because they know they have a checkpoint or a
governance review coming up. We have brought
in talent with needed skills and competencies
such as product marketing. We are making
better investment decisions to accelerate
growth, gain portfolio leverage and ultimately be
more competitive. All of this is leading to more
collaboration across functional teams.
We’re working to grow the language of
Pragmatic Marketing within the organization.
Getting ourselves thinking the same way was a
big feat. Terms like “NIHITO” (nothing important
happens in the office), “roadmap,” “solution
strategies” and “buyer personas” are now
becoming part of our basic dialogue.
The Future Looks Bright
Transformation doesn’t happen overnight and
there is still work to do. What we are applying
from Pragmatic Marketing is foundational to
our long-term growth, and best practices are
being leveraged across other business units. Our
customers are starting to see the differences in
the way we show up in the market and engage
the community. That is the ultimate test of
success—being a thought partner and driving
value for our customers. After all, it does start
with an understanding of the market problem!
About the Author
Dana Jones is senior vice president and chief marketing
officer for Sabre Airline Solutions. A seasoned product,
marketing and operations software executive with over
17 years of experience building successful technology
businesses, Dana joined Airline Solutions in 2012
and leads the Marketing and Solutions Management
organization.
PM
Pragmatic Marketing gave us
tools to put portfolio management
disciplines in place.

In the age of information overload, ensure
your communication hits the mark. By Nick MorgaN
Four Power Cues for Leaders
Lead Strategically
W
hen I was 17, three events led to my lIfelong Interest in body
language and communication.
The Dalai Lama became a hero to me. I read a
book about the Dalai Lama, whose escape from Tibet under threat
from the Chinese was both terrifying and heroic. The fact that he
could then become an apostle of peace and brotherhood in the
world made him a hero of mine.
Six years later, I went to hear him speak.
He was an hour late, but we all waited. When
he arrived, he walked to the middle of the
stage and sat down on the floor—and then
he didn’t say anything. He just looked at
us for about four minutes, and it felt like
an eternity.
Then he let out this unearthly laugh
and said, “I better say something really
intelligent, because I kept you waiting for so
long.” He gave a fine speech on Buddhism,
but the real power of that experience was in
those four minutes of silence. As he looked
at us, it felt like he made a connection with
each person in the audience. I wondered:
“How did he do that? What did he share with
us silently that was so powerful?”
I learned my father was gay. At
Christmas, I bought my dad a book I found
in the bookstore by E.M. Forster, “Maurice.” The book wasn’t
published until about 50 years after Forster’s death, because of its
homosexual theme. I had been dimly aware of the back story, but I
just thought “great writer” and wrapped it up to give to my dad.
When he opened it, he gave me this funny look. It was just
a brief glance, but something about it made a wheel turn in my
head and I just knew my dad was gay. When he really came out to
me 10 years later, he hemmed and hawed—and I finally told him
that I already knew based on that look at Christmas.
He didn’t remember the moment, and I thought,
“Extraordinary, how can somebody reveal a lifetime of secrecy in
a glance and not be aware of it? What is going on there in terms
of the body language—signals sent, signals received—that the
sender isn’t even aware of?”
I died. I went tobogganing just after
that Christmas, and my friends challenged
the daredevil in me to go down by myself.
I didn’t even make it around the second
turn. I crashed into a tree head first and
fractured my skull.
I was in a coma for about a week,
and I even flatlined for about 15 minutes.
After surgery, I came to and passed the
basic tests they give you for neurological
events. But I didn’t know how to vocalize
something that had changed: I could
no longer read people’s body language
in the way everybody else could. You
know how you can walk into a room of
colleagues or family and can get a read
on whether people are happy or sad
without anything being said? That was
gone for me. Also, while I could hear the
words people were saying, I couldn’t hear any of the emotion
behind it, such as sarcasm or irony. For a 17-year-old, that’s really
important because you are often mostly humorous, ironic or
sarcastic. (I’ve since been told that what I was experiencing is
similar to some forms of autism.)
I started studying people’s body language very closely
to try to figure out what was going on. I spent many months
He gave a fine
speech on
Buddhism, but
the real power of
that experience
was in those four
minutes of silence.

retraining myself, and it eventually came back.
Together those three events taught me about aspects of
body language and communication—and specifically how we
create meaning, make decisions and express emotion through
communication. We’ve evolved so that all of those things
are expressed largely unconsciously and they are out of our
conscious control.
The Vast Unconscious
Your unconscious mind can handle somewhere near 11
million bits of information in a second. It’s always scanning the
surroundings, reading the intent and emotions of the people
around us and seeing whether they present a danger or not. Our
conscious minds, by contrast, can only handle about 40 bits of
information per second.
When we were largely reactive cave people, it made a lot of
sense to have feelings like uneasiness be unconscious. If you’re
being chased by a woolly mammoth, you don’t want to spend
a lot of time thinking consciously about it, you just want your
unconscious mind to get you the heck out of there.
But in the modern era, there is a lot that it would be better to
be more consciously aware of. Wouldn’t it be better to be able to
consciously control our emotions? Or the meaning we interpret or
present when people talk to us?
I worked with an executive who was cool in crisis and was
therefore promoted throughout his career in the utility industry—a

good place to be cool in crisis. But then he was promoted to a
very high level that reported to the board, and the board said,
“We no longer want you to be cool in crisis. We want you to be
more motivational, emotional and supportive of your team.”
So he suddenly had to learn to take conscious control of his
emotions and express them better than he had before.
In another instance of trying to become conscious of what
is mostly an unconscious act, I did some work with the U.S. Air
Force Special Ops a few years ago. A team was being trained to
go into an undisclosed foreign country and set up infrastructure
like airfields and even a small town. They had to work with the
local population, and so they wanted to know how to read the
intent of the population before action was taken. Basically, if
someone in this country is coming toward me, I want to know if
this person intends to shoot me or shake my hand.
Again, that’s largely conveyed by unconscious body
language. And as adults, we learn to disguise that body
language to a certain extent. We learn to compose our faces.
So if we’re sitting in a meeting and the meeting is boring, we
don’t make the kind of faces that children do when they get
bored—because we’ve learned to be polite. But our bodies
still tend to give us away, largely unconsciously.
I’m going to share four power cues that can help you to
control the elements of communication.
1. Become Aware of Your Own Body Language
When I talk about this in a presentation, I ask the audience to
freeze in place. I then ask them to notice how they are standing
or sitting, if their shoulders are slumped, if their backs are
straight and if their heads are pitched forward. (Of course,
sometimes people move and adopt better posture.)
The point is to become more aware of your posture,
because that’s the first way you signal your intent and your
emotions to people. We each have “mirror neurons” in our
heads: When we see somebody else experience an emotion,
Lead Strategically
You can change and
control charisma by
focusing your emotions.
we fire that same emotion in our head. We’re empaths, picking up
each other’s emotions and leaking emotions to each other.
For an important meeting, you need to think about your
emotional state; otherwise you’re leaving it to chance. Maybe
you’re nervous about the meeting—then you’re going to leak
that mishmash to the other attendees. It’s not charismatic, and it
doesn’t set you up to be a leader.
Being aware of my own body language helped me land a job
a few years ago.
I met the executive at a midscale seafood restaurant here in
Boston—and he ordered the biggest lobster on the menu for me.
I didn’t know that in the few years since I’d last eaten lobster,
I had become allergic to it. So I started eating the lobster and
my throat started to close and I began to choke and turn red. But
I really wanted the job, so I excused myself and got sick in the
bathroom—and then continued the interview.
I was determined to get the job. I began mirroring the
interviewer’s behavior across the table to gain his trust. (You have
to do this subtly, because if you do it too obviously you’ll look odd
and the other person will catch on to what you’re doing.)
When we see someone mirroring our behavior, we don’t think
about it consciously—only unconsciously. Then what happens is
you start to trust that person, because when two bodies move
in the same way, they are saying, “We are in agreement; we’re
in sync here.” You see this with two people who trust each other
completely. They make the same gesture virtually at the same
instant. It’s very hard to tell who leads and who follows. It’s really a
beautiful sort of synchrony to watch.
So that’s what I was doing with my interviewer, mirroring him
until he began to feel that he could trust me and that I was in
agreement with him—which meant I would be a good hire.
2. Focus Your Emotions
People often ask me what charisma is and if it’s something only

a few lucky people, like movie stars, are born with. The answer is no. We are all
occasionally charismatic.
Look back to when you were a child at school and something wonderful or
terrible happened. You came home and you were full of that emotion, whether it was
joy or sadness.
Because you were so focused and so completely engulfed in that emotion, your
parents probably looked at you and asked you what happened. They wanted to know what
was going on. They could tell you had experienced something because you were radiating a
strong emotion. That’s charisma; it is focused emotion.
Once you become more aware of how you show up, you can start to change and control
charisma by focusing your emotions before important meetings, speeches, big negotiations or
conversations with higher ups—anything that you feel is important where you want to show up with
a powerful, strong presence. The work involved is focusing your emotion beforehand.
I often ask people about their presentations, because most people in the business world have
to do those at one time or another: “How much time in preparing for a presentation do you spend
thinking about the content and how much time do you spend thinking about the body language?”
The real, honest answer is always 100 percent on content, 0 percent on body language. But when
those two things are aligned, the body language will always trump the content if you
don’t focus your emotions.
3. Learn to Read Other People
You also need to notice the unconscious signals that other people are sending.
You’ll begin to be able to recognize and understand what others are thinking
before they even know it. That’s because emotional attitudes and decisions are
made unconsciously at first, then gestured about and then brought to the conscious
mind. You’ll learn to see the attitude or decision at the gesture stage, before the other
person is aware.
This helped me quite literally survive my interview at the lobster restaurant. After
mirroring my interviewer’s gestures for a while, I eventually started making new gestures—and
he started mirroring mine. As soon as he did that, I knew I could stop eating that lobster and
relax, because he was going to give me the job. Sure enough, he called me the next morning
with the offer.
This is not manipulation in that you can’t make people do something they don’t want to

If leaders tell
compelling
stories aligned
with their body
language, they
would be much
more successful.
do. It was within that man’s power to offer me the job. And by
mirroring his behavior and making him feel like he could trust
me, I greatly accelerated that process and enabled him to come
to a decision. Had I been nervous and twitchy and not given
attention to body language, I might not have built up that trust or
gotten the offer. You can actually read people’s minds and know
what they’re thinking—and you can use that knowledge to build
agreement and alignment with them.
4. Put It All Together with Powerful Stories
Uri Hasson at Princeton University found that when we tell each
other stories, our brains match each other, looking
exactly the same on a brain scan. And so as
a leader, if you tell somebody a good,
strong story to get them enthusiastic
about a job you want them to do or
a product you want them to help
develop, then you can make
them think the way you think. It’s
a literal, actual version of that
Jedi mind control trick.
Hasson’s research also
shows that if you tell somebody
a good story, the listeners are
actually a nanosecond or two
ahead of the storyteller. Not only
do you have them lined up with
you, but they’re pulling you along
at that point. It’s like a kid who knows
you’re heading toward the ice cream
store and they’re tugging you along, saying,
“Hurry up!” You’re not only making them think in
a certain way, but they are doing a lot of the work
for you.
The whole point of power cues is really to enable us to
become aware of the unconscious signals we’re sending
out so that we can control them and put them in service of
powerful storytelling.
Once you’ve got the steps that have to do with body
language mastered, you can be an effective storyteller and
leader by aligning your body language so that it is in service to
that content.
There are five basic powerful stories we tell each other that are
buried so deep in our psyches, because we’ve heard them in one
form or another so often, that they affect the way we see reality.
We have no actual control over reality, but these stories give us
an illusion of control. We tell ourselves these stories to help us
structure reality, to help make sense of it.
If you tell one of these five types of stories and tell it well, then
as a leader or as anyone trying to get something done in
an organization, you’re much more likely to have the effect
that you want.
The quest. This is the story that’s familiar from so many
Hollywood movies. A hero goes out to try to achieve a specific
goal that we find alluring. When we tell a quest story, we know
that the journey is going to have lots of ups and downs along the
way. But we believe that the harder we work to reach the goal, the
more likely we are to achieve it. Now that’s not strictly, logically
true. A student who heads off to college with good
intentions and works really hard could still have
plenty of things go wrong. But we don’t
include that in our thinking about it. We
tell ourselves quest stories because
they are what enable us to have
a belief that hard work pays off
in reaching a desirable goal.
And it’s important to believe,
otherwise we wouldn’t
try, work hard and keep
persevering.
So it’s a story, but it’s
also part of a deeper belief
system—and that’s why it’s so
powerful. When you tell a good
quest story, people love it, listen
and want to get involved.
Stranger in a strange land. In
this type of story, there isn’t a particular
goal at the end. Some kind of change is
foisted upon the hero and the rules are changed.
The classic example of this in the business world is 2008,
when the economy melted down. Suddenly, everybody was
wondering if there was a new normal. Do the old economic rules
no longer apply? Are we going to have to learn new ways of
doing business?
The stranger in a strange land is thrown into a new situation
or a new terrain and has to learn a new way of coping and a new
set of rules to become a master in this new landscape. Sometimes
a mentor comes along to help us, and sometimes we must do it
on our own. And so the stranger-in-a-strange land story
helps us cope with change.
Rags to riches. This is the type of story the
networks tell every time the Olympics come
around. Every single one of those athlete
stories is a rags-to-riches story because the

Lead Strategically
PM
Learn to build strategic teams in our
Foundations course.
pragmaticmarketing.com/foundations
riches aren’t necessarily just money. They can
be celebrity status, honors or gold medals. And
the difference between a quest and a rags-to-riches
story is the plucky hero that achieves the status by hard work
and a little bit of luck. And so that’s why the Olympic stories all
focus on the time and practice the athletes put in, not on some
unique inborn physical attribute that might give them the right
physique for a particular event.
If we believe that a gymnast was so talented because her
genetic makeup was just suited to gymnastics, we wouldn’t
identify as much. We’d think that talent was unattainable to us no
matter how hard we worked.
The important thing about the rags-to-riches story is that
every man or woman could achieve the same result, provided they
put in all the time and had a little luck. We tell our rags-to-riches
stories to say that even people born without silver spoons in their
mouths can get ahead. It’s a story that isn’t told as much now,
because it’s been brought powerfully into question. We’re asking
these days if the American dream is still viable, because the times
have been hard for many years. Can ordinary people still achieve
that kind of wealth? That’s the interesting tension right now in the
rags-to-riches story. Does it still work?
Revenge. This is a powerful one right now, because we have
a sense that there’s a lot of wickedness in the world between
chaotic, random shootings and the digital world’s representation
of war and injustices. We’re keenly aware of the need for justice,
so the revenge story has power for us.
In the revenge story, the hero sets out to right some wrong.
Sometimes it’s a specific villain, but sometimes it’s an institutional
villain like a war. And then justice is done. It’s a very important
story to us. We need to believe that justice is possible, otherwise
we wouldn’t all behave. Why would we play by the rules?
Love story. This is my personal favorite. Hollywood calls it a
romantic comedy, and it is considered one of lower movie genres.
But it is really important, because at its base, a love story tells us
that community is still possible (since the smallest form of human
community is two people).
In the traditionally told love story, a boy meets a girl, the boy
falls in love with the girl and then the boy does something stupid
and they fall out of love. Later, the girl forgives the boy. They
now know each other as real, flawed human beings and not just
that initial fantasy that they fell in love with. So the girl forgiving
the boy is a powerful statement of the possibility of human
community. If they can still fall in love again or stay in love despite
their flaws, then forgiveness and community is possible. If we
didn’t have that story, then perhaps we wouldn’t believe that we
humans could remain in a community with one another.
We live in an information-saturated age. We have 24/7
access to enormous amounts of data at our fingertips. We’re
completely overloaded with it and our minds are not constructed
to remember that stuff.
The mistake that leaders make all the time is they try to give
their employees or their people to-do lists: Here are the things we
have to do to succeed.
Steve Jobs of Apple was so successful because he didn’t
say, “Here are the cool features of the Apple computer.” What
he said was, “We can strike a blow against conformism, against
Big Brother. We can do something cool and neat. We can create
computers that will set you free.”
If leaders tell compelling stories aligned with their
body language, they would be much more successful. That
communication attaches emotions to events and make them much
more memorable.
About the Author
Nick Morgan is a top communication theorist and
coach, who is committed to helping people find
clarity in their thinking and ideas—and then deliver
them with panache. He served as editor of the
Harvard Management Communication Letter from
1998 – 2003. He is a former fellow at the Center
for Public Leadership at Harvard’s Kennedy School
of Government. After earning his PhD in literature
and rhetoric, Nick spent a number of years
teaching Shakespeare and public speaking at the University of Virginia,
Lehigh University, and Princeton University. He first started writing
speeches for Virginia Governor Charles S. Robb and went on to found
his own communications consulting organization, Public Words, in 1997.
He is the author of “Working the Room: How to Move People to Action
through Audience-Centered Speaking” (Harvard Business Review, 2003)
and “Trust Me” (Jossey-Bass, 2009).
Editor’s Note: For more about Power Cues, read Nick Morgan’s book, “Power Cues: The
Subtle Science of Leading Groups, Persuading Others, and Maximizing Your Personal
Impact” (Harvard Business Review, 2014).

A PrAgmAtic APProAch
Put this issue’s ideas into action.
Know Your
Minimum
Establishing the
minimum viable
product as a
baseline clears
the landscape for
stickier rounds of
negotiations.
Mike Hughes
Be a Good
Listener
Remember that
every team member
can inspire product
solutions.
Julie Babb
page10
page25
Set Priorities
Force prioritization
at every sprint to
avoid difficult last-
minute decisions.
Mark Lawler
Make the
Most of
Content
Video content
can be posted
on YouTube,
transcribed for blogs
and shared across
social channels for a
bigger bang.
Brandee Sweesy
page13
page 27
Cater to
Your Buyers
Be aware of the
individual buyers
making individual
buying decisions
surrounding your
product.
Jim Ewel
Ensure
Consistency
A content standards
guide can help keep
messaging, tone
and voice consistent
across all media.
Sandra Jean-Louis
page17
page28
Focus on
What, Not
How
Communicate
problems to be
solved, not product
specificatons.
John Milburn
Communicate
Cross-
Functionally
Communicate
key changes and
business rationale
with field-facing
teams to enable
strategic customer
conversations.
Dana Jones
page 21
page33
Collaborate
Versus
Participate
Use a tech
background to
speak better with,
not at, developers.
Scott Sehlhorst
Stand Up
Straight
Your posture is the
first way you signal
your intent and
emotions to others.
Nick Morgan
page 23
page36
Sign up for your free
subscription, delivered quarterly via email,
at pragmaticmarketing.com/subscribe.
Share this issue >

pragmaticmarketing.com live
Pragmatic Live
is back on the air.
Our monthly webinar and podcast series will help you conquer
your greatest product management and marketing challenges. It
offers best practices and tips, as well as an inside look at how they’re
being implemented in some of today’s most successful companies.
So, if you’re looking to stay tuned in to the latest in technology, look no further than

Practical Training.
Proven Results.
Pragmatic Marketing offers a
complete curriculum designed to
help companies build and market
products that sell. Our courses provide
real-world insights, actionable best
practices and proven tools that will
maximize your impact.
So, whether you are responsible for
determining what should be on the
shelf, or how to make it fly off the
shelf, we have a course for you.
For more information about these courses or our
executive offerings, visit www.pragmaticmarketing.com
or call 480.515.1411 today.
To determine which courses are right for you click on the video
below or go to pragmaticmarketing.com/PragmaticCourses
Foundations
Implement a proven,
practical blueprint for being
market driven.
Focus
Use market data to identify
and present the right
product strategies.
Build
Align product and
development teams to build
remarkable products.
Market
Focus your team on the
marketing strategies that
deliver results.
Launch
Elevate your team’s product
and marketing launches.
Price
Set the right price for each
product in each market.

Pragmatic Marketer Summmer 2014

More Related Content

What's hot (15)

Viewers also liked (20)

Similar to Pragmatic Marketer Summmer 2014 (20)

More from Pragmatic Marketing (19)

Recently uploaded (20)

Pragmatic Marketer Summmer 2014