One Goal to Rule them All…

This is the second part in a series on cross functional teams. You can start from the beginning here.

By JON NYLANDER

Successful product development does not come pre-packaged with wizened product elders who gather up a bunch of unlikely heroes in order to accomplish a goal that is both set in stone and seemingly impossible to reach.

Great products are built by teams who embrace disillusionment, who expect and revel in change, who do not cling to beautiful hypotheses as if they were proverbial Mount Dooms that they simply had to reach, no matter what the cost. But they do need goals. Lots of different goals, with different time horizons, different priorities and of different sizes. And they need these goals to compete with each other.

Sam and Frodo had no choice, their only option was to conquer Mount Doom. But in product development there is no Mount Doom. There are no know-it-all authorities to point it out to you. There are rather many concurrent goals and many different stakeholders that compete with each other for the spotlight. Product development is the work of open-mindedness, not single-mindedness.

Goals are only another way to communicate value. And when we talk about goals and weigh them against each other, we open a channel for negotiation regarding the single most important question in product development:

Are we doing what is most important right now in order to provide the most value in the shortest possible time?

Detached Goals

Every organisation has some sort of vision or goal statement in place. Typically this goal is set in place by management and is communicated at least yearly. Perhaps incentive programs are in place to adjust compensation in line with goal achievement.

But ask yourself: when was the last time you used that goal to decide what to prioritise in your daily work?

This is the scourge of detached goals. They may be critical to your organisation, and therefore they must exist. But unless they are moulded into shapes that are appealing to the craftsmen that make up the productive forces of your company; they are useless.

If you are working with product development, and if you are using cross functional teams to accomplish that work — your main job is to formulate and negotiate goals that make sense for product developers.

Therefore, the values and the processes that you use when you set goals are infinitely more important than the actual goals. Shared processes and values are what make it possible for people to align towards common things, i.e goals.

Processes and Values to Align People

Cross functional product teams need to constantly talk about value to the client. Creating value is what they can contribute towards a profitable company. Though profits are indeed testament to created value. Discussions on “client value” cannot take place on the level of revenue or growth, they must have a different point of reference.

If you have recruited the right folks to your cross functional teams they will have a very real interest in solving problems and increasing the value of a product. It is therefore important to find a context in which these discussions can take place.

A slightly modified version of vanilla user stories are my preferred context. First of all, when you force yourselves to formulate everything in terms of user stories you will start to shape a sophisticated culture of shared taxonomy and understanding. You build empathy and understanding for your client personas. Conversely; if you come to a team with old-school feature requests, you will have a much harder time explaining and understanding value.

Imagine that you are a product owner, walking into a weekly grooming session for a team. Which of the following statements do you think would form the basis for a good negotiation with the team?

1. We need to make it possible to drag and drop items from list A to list B because list A always becomes so cluttered.
2. As a user I would like to have a clutter free overview so that I can focus on what is important and get things done in the right order.

The first option will land you in an immediate Mount Doom scenario — there seems to be only one way forward and if you disagree with that particular solution you will have to handle a conflict. The latter formulation however is an invitation to innovate and to do it as quickly as possible. It is the user story variant of discussing value that will build sophistication and a culture of client understanding in your teams.

Formalising Empathy with Enriched User Stories

Imagine again that you are a product owner and you walk into the weekly grooming session for a team. Imagine also that the Sales Director has expressed serious concern with retention, and has even approached you with a specific feature request. Which of these three formulations do you think will render the best and quickest outcome?

1. “We need to add the drag and drop feature right now, we’re losing business over how cluttered the overview is!”
2. “As a user I would like to have a clutter free overview so that I can focus on what’s important and get things done in the right order.”
3. As Eve (our Sales Director) I would like to see that retention is prioritised more, so that I can worry less about the people who threaten to leave on account of the cluttered overview.

As you can see, each of these formulations may result in the same actual actions being undertaken. Perhaps a drag and drop solution will in fact be implemented. But if you are using story number three, you leave yourself open to take responsibility for both internal and external expectation management. The team may be aware of other problems which are even more detrimental to retention than a cluttered overview, naturally they should be acted on first. Enriched user stories are a framework in which such initiatives can gain acceptance and get support from stakeholders.

Another example of an enriched user story could be “As cross functional team X we want to focus on regression tests and refactoring until we have covered feature Y so that we can sure up quality and provide robust value even faster as we move forward.”

So I am suggesting that you use user stories not exclusively to negotiate client focused needs. Many times internal goals are equally important and perhaps even harder to empathise with. The beauty is that more often than not, internal and external expectations are possible to address simultaneously.

Using enriched user stories, i.e stories that take into account the needs and goals of external as well as internal personas is an option if you want to formalise empathic relationships, thus simplifying communication, and in the end get people to aim for the same things, whatever those things may be.

A cross functional team schooled in enriched user stories will be a superb speaking partner when discussing product development efforts. They will help you answer questions such “why are we doing this?” and “how can we validate whether we are on the right track as quickly as possible”, and the ever important question “is this goal still valid?”

Wrapping it up

Goals are a way of communicating value and direction. User stories are a means of formalising empathy and understanding for clients. Enriched user stories combine internal and external needs. Sophisticated user stories are loaded with value propositions and viewpoints, which can be prioritised, understood, negotiated and acted upon. User stories are goals.

Phew. Get it?

—

PS. Liked this article? Consider clicking the green heart or sharing. Thanks!