Agile Know-How Magazine • Fall 2017
Agile transformations are often initiated
by production teams that believe
Agility will empower them to deliver
better products in a shorter time.
O
rganizations speak of “faster time to market” and “higher
quality.” They look at the cost and green-light the proposed
transformation. Reality is that often these teams successfully
decrease their delivery time without really improving the way
they think up their products, that is to say, without using
Product Agility. And faster delivery of poor products is still
a losing proposition.
The main value of an Agile transformation is the ability to
react quickly to complex market conditions, and this includes
turning a losing proposition into an award-winning product.
The story of how Design Thinking helped Airbnb make that
exact transition is a classic example. Not helping your teams to
achieve Product Agility takes away the main benefits of your
transformation.
Here, we will outline three impediments to Product Agility that
are often encountered in organizations and explain how to
overcome them.
1
Not having user-centric product management
practices
In traditional organizations, product management decisions
are often based on long-running assumptions about users, such
: as believing, like Kevin Costner, that if you build it they will
come. 1
Product plans are made several months ahead of time for
budgeting reasons and are rigorously monitored to remain
on scope, on budget, and on time. In the conversations, we
hear more about “projects” and “resources” than “needs” and
“users”. In fact, nowhere in the process is the user involved.
As each assumption carries the risk of being wrong, the likeli-
hood of reaching a product/market fit is not improved by the
transformation.
Here are three tips to help refocus product development on the
user:
• Stop talking about projects, which is a way to track work
units, and start talking about products at the service of real
users.
• Refrain from talking about features and solutions until the
very last moment. Instead, talk about users, needs, and value.
Stop talking about projects
and start talking about products
at the service of real users
• Most importantly, include the user in the conversation. Re-
member the old telephone game where a message is carried
over a string of individuals, one after the other. The end
message is never the same as the original one. The same
applies to the understanding of users’ needs. Having
nonusers relaying information to the team working on the
solution carries many assumptions. To avoid this, direct
contact with users is needed. Some approaches mention
bringing the user into the team, others encourage the team
to go “out of the building” and to wear the user’s shoes. In
the end, we want a collaboration that enables us to better
understand what needs to be done.
2
Not validating hypotheses
An assumption is believed to be true, while a hypothesis is no
more than a guess. In The Four Steps to Epiphany, Steve Bank
identifies various categories that regroup the hypotheses that we
make while developing a solution and that should be validated.
agileknowhow.com
43