Agile

Remember first year physics?Speed is a measure of distance over time.Velocity is a measure of displacement over time. Velocity is a vector: it has direction.

We all know the sensation of running really fast (having high speed) but not making much progress toward our goals (having low velocity).

The red queen has a lot of speed (she is running as fast as she can) but she never leaves the spot she is standing on: the chess board is moving just as fast as she is, and her displacement is zero: so her effective velocity is zero.

The winner of the Berlin marathon ran the course in slightly over 2 hours: an average speed of about 20 km/h. But he finished exactly where he started: all that running to end up back at the same spot. His velocity, after two hours, was zero.

On projects and teams, velocity matters a lot. Velocity is the measure of how much progress you are making towards your objective, your end goal. No matter how fast you’re moving, if your velocity is low, your progress will be slow.

Scrum teams often have a measure of progress called velocity that measures how many user stories were delivered in a given sprint.

But what if those user stories didn’t add any value for the customer?

Stories delivered over time is a measure of speed. I better measure for velocity is:

Increasing speed can increase velocity. But it can just as easily decrease it.

Good speed is efficiency, focus, and delivering the things that your customers care about and that make a difference for your business.

Good speed is asking: how can I make this two-day task into two one-day tasks?

Bad speed is rushing, burning out and piling on technical debt. It’s building features that nobody uses, that your customers don’t care about and that don’t add value to your business. It’s prioritising business needs over customer needs. It’s waste.

Bad speed is asking: how can I make this two-day task take one day?

When you find yourself rushing to speed up, ask yourself: is this good speed, or bad speed?

In idea is not a business; and it’s not a product. An idea is just an idea.

What makes an idea ready to become a product?

Facts.

An idea made up of only opinions is just that – opinions.

Don’t get me wrong: opinions are often sensational places to start a product from. Some of the most ground-breaking and innovative products started with an epiphany, a flash of inspiration or a daydream. The trick to being successful as a creator of products is to figure out which ideas are productisable – and which aren’t – before you build and launch a product and watch it fail.

Identify the intrinsic assumptions that exist within your idea, and then test them.

Avoid making product decisions on ideas or opinions alone. Testing the assumptions behind the great ideas is the only way to know you’re investing your time and money into the right product.

Customer involvement and user feedback is at the core of building great software experiences that people want and love.

It’s a bit old now, but I just stumbled on this impressive way to build an app with customer feedback at the core. Nordstrom innovation lab built an iPad app in just one week to help people pick sunglasses. To better involve customers and user feedback in the development process, they built the app in a sunglasses store!

In improvisation theatre (yes, I was a theatre nerd in high school) there is a concept called blocking. Essentially, whenever you have an interaction with someone on the stage in improv, your interaction should allow the next person to pick up the thread and run with it to continue the scene. In other words, you need to provide a hook for the next person to continue the story.

If you don’t provide a thread for the next actor to continue the scene, it’s called ‘blocking’, as you’ve essentially blocked the scene from proceeding.

A quick example:

Actor A: “Do you want to go for a walk with me?”
Actor B: “No, I don’t feel well.”

B has blocked A’s offer to go for a walk, without providing an alternative option for the storyline, leaving A with the responsibility for creating a new storyline for the scene.

In development teams I see people blocking each other all the time.

Another example:

Developer A: “Can we add an extra parameter to this function?”
Developer B: “No, it doesn’t work like that.”

Developer B has blocked Developer A from solving the problem, without giving A another thread to follow. In other words, B has shunted the topic back to A, leaving A with the responsibility to try to find another way to attack the problem, but with no extra cues from B on what might work better next time.

Saying ‘no’ is not the problem here. But when you say ‘no’, you should always try to give a thread to allow the scene to continue.

Let’s try the example again:

Developer A: “Can we add an extra parameter to this function?”
Developer B: “No, it doesn’t work like that, but if you look at the sample requests you might get an idea of what’s working already.”

Now Developer A has a thread; she has an idea where to go to continue the search for the solution.

Not blocking someone can be as simple as giving a cue to let the scene continue. So when interacting with people in your team, or with other teams, remember: everybody wants the scene to continue, so avoid blocking.

The product owner is possibly the most misunderstood, or at least the the least understood, role in agile software projects. Just about everyone you talk to, whether a current practitioner of the role or just someone who works in agile projects, will give you a slightly (or greatly) different description of the role, its scope and its value.

A colleague recently asked me to write down for him a brief description of everything I thought a Product Owner should be, in terms of role and responsibility as well as personality and competencies. As I started considering what this would be, a few things occurred to me:

The list of responsibilities is very broad. The better product owners understand all aspects of a product from the value proposition and business model to design to development.

The predominant literature on agile product management focusses heavily on the agile process and toolkit: working with scrum or other agile methodologies, continuous delivery, refinement of user stories, etc.

The traditional (non-agile) literature on product management as a profession is plentiful, but fails to address how the broad scope of product management skills and competencies relate to an agile environment.

I’ve now set out to produce a series of posts which will form my personal description of “the complete product owner”. I’ve chosen the word “owner” intentionally to relate specifically to the field of agile product management (as opposed to, let’s say, “traditional, waterfall” methodologies. More on product owners vs managers soon.) The word “complete” refers to the intention to provide a complete, end-to-end view of the scope and responsibilities of this role.

It is also important to mention at this point that what follows will be most relevant to the traditional home of agile methodologies: in software development. It is interesting to observe how agile techniques are being adopted by industries as diverse as medical research or construction, however the experiences, analogies and resources in this series will be exclusively focussed towards software product management.

What’s in a name? Product Owner versus Product Manager

The traditional industry title for those in the business of managing the product development life-cycle is the “Product Manager”. Agile methodologies, specifically Scrum, introduced the term “Product Owner” to refer to the member of the scrum team (ie, the product team) who is predominantly responsible for the product itself (predominantly, as in agile teams we strive to embed a feeling of product responsibility in everyone, throughout all levels of the product organisation).

Some people misinterpret the difference as a reflection of the scope of the role, assuming that the “Product Management” discipline is broader or more “senior” than an owner. I take a very different view, and argue that there is no difference. It could be perhaps said that within the Product Management discipline, a Product Owner is one who practices within an agile context; however there is certainly not, in my view, an assumption that the scope and responsibilities of a Product Owner are necessarily any different to that of a Product Manager.

In my writings I use the two terms interchangeably; however it is useful to remember that in certain circles the title “Product Manager” is often understood differently from an “Owner”. Specifically in non-software product industries (fast-moving consumer goods, among others) the term “owner” is less relevant.

What is a Product Manager/Owner?

In his famous 1955 work “Designing for People”, Henry Dreyfuss, considered my many as the father of modern industrial design, said the following about the role of the industrial designer:

“The successful performer in this new field is a man of many hats. He does more than merely design things. He is a businessman as well as a person who makes drawings and models. He is a keen observer of public taste and he has painstakingly cultivated his own taste. He has an understanding of merchandising, how things are made, packed, distributed, and displayed. He accepts the responsibility of his position as liaison linking management, engineering, and the consumer and co-operates with all three.”

Although he was talking specifically about the industrial design discipline, I think he has equally perfectly described the role of the modern product manager. (You’ll forgive his gender bias, but it was the 50’s after all). The complete product manager is a jack of all trades. It’s someone who can keep the big picture in mind while obsessing over the smallest details. It’s someone who can, on the same day, discuss or consider engineering process, marketing strategy or interface design – all in terms of how it relates to the core consumer value proposition.

A complete product owner:

is a technologist,

is a marketer,

is a strategist,

is an entrepreneur,

is a risk-taker,

is a visionary,

is a leader,

is passionate,

is a networker,

is a communicator,

is a presenter and speaker,

is a thought-leader,

is a product expert,

is a salesperson,

is fluent in software experience, language and technology,

understands user experience/user interaction paradigms, and

understands software development methodology and software development tools and processes.

Where do product owners come from?

The next time you meet a product manager, as an experiment, as them how they became a product manager. If you are a product manager, think about how you became one. If they attended university, ask them what they studied. The answers may surprise you.

Nobody will tell you that they studied “Product Management” at university. Some will have studied Computer Science, others design, still others psychology, business or even philosophy. Nearly nobody will tell you that they “always wanted to be a product manager”. Many of the product owners that I know say they kind of “fell into” the role. I sort of did, too.

Steven Haines calls it the “accidental profession”. The interesting mix of backgrounds and motivations does result in a healthy range of experience and perspectives in the product management world, but it has, I think, the side-effect of producing a problematic diversity in product management approaches and levels of training.

What’s next?

The Complete Product Owner series is broken into four acts. Each act is centered around a main theme: The Product, the Business, the Team, and you.

Some topics don’t fit neatly into a single act. In fact, most don’t. You can’t discuss product strategy without discussing design; you can’t think about market segmentation without thinking about the competitive landscape; and so on.

Within this series, I won’t be able to teach you everything you need to know. I can’t teach you how to do brand marketing or search engine optimisation, for example. The purpose of this series is to discuss the scope of areas, skills and knowledge a Product Owner should understand, what they are and why they’re important; and then potentially provide some links to resources for those who want to know more.

Act I: The Product

Much of the books or literature on product management tends to start with the process and definitions, and leave the actual product to the end, almost as an afterthought. To me, everything starts and ends with the product itself – so we start with the product here. We’ll look at defining what the product is, what it does and who it’s for.

Act II: The Business

The next aspect is the one that I see most often neglected by new and experienced product managers alike. The business is, if not the core element of a product team, the surrounding ecosystem that enables and supports the product development. Smaller teams and startups are intimately familiar with the importance of such business tasks as raising capital funding or developing a competitive business model, but these can go unseen or be neglected in larger teams.

Act III: The Team

This is where most product owners, particularly those new to the profession, spend a disproportionate part their time. The team is where things get done, or “where the rubber hits the road”. Having a functional, efficient and self-organising team is a critical focus for teams. For Product Owners, it’s critical to understand how the team supports you and how you support the team to ensure the greatest success.

Act IV: You – the Product Owner

Once you know what you need to do: the tasks, the responsibilities, the focus areas; how you actually do it is up to you. We’ll look at a number of key skills and competencies that you should focus on developing to be a complete product owner.

Here we go…

So let’s get started. In the first post in the series, we’ll look at defining the product: what it is, who it’s for, and why the heck you’re building it anyway.

I would love for this to be as interactive as possible. If you have questions or comments; if you agree or disagree with what we discuss here, please let me know in the comments.

One is the hunter; the other, the hunted. One stalks and sprints with total precision, unwavering focus and ultimate confidence. The other flees in uncontrolled panic.

When we’re exposed to pressure within an organisation, it is normally in the form of a risk or a threat: the risk of losing a big client; the chance we won’t get funding; the fear of losing our jobs.

The fact is that all mammals, including humans, are really good at panicking. In fact, we’re designed for it. Buried deep inside the oldest part of our brain is a brain region called the limbic system. In evolutionary terms, the limbic system existed long before we first picked up a rock and used it to hit something. It’s the part of our brain responsible for basic survival; it’s the part that takes over when we’re scared, angry, lusting for revenge or when we’re threatened.

When we feel threatened, our limbic brain sends some signals to a part of our central nervous system called the sympathetic nervous system, which activates the so-called “fight or flight response”. Our conscious brain (the cerebrum) more or less shuts down and the limbic brain takes the wheel. It will decide whether we flee or whether we fight.

This is the response that leads us to panic. But when we panic, we lose focus. All our effort goes into outrunning the cheetah… but a gazelle can’t eat, drink or make baby gazelles when it’s fleeing a chasing cheetah.

If we spend all our time running, we don’t focus on the important things. We might increase speed but we end up losing velocity.

We all have many reasons to panic… The market is moving quicker than ever. Markets and industries change and heave, companies rise to incredible heights or crash to the floor in a fraction of the time of 20 or even 10 years ago. We have to move with urgency if we want to keep up… but urgency isn’t panic.

Factories must be awfully dull places. Factory workers working on a production line follow a strict process. Work is divided out into narrow and highly controlled portions. The guy working at machine #1 is an expert at machine #1, but not at machine #2 or #3. But that’s ok; if he stays focussed on his machine, the production line moves on and many widgets will roll off the end.

Factory workers take a given process or specification and assemble it. That the solution is provided is a given. There’s no room for initiative or individual innovation on the factory floor. If one machine doesn’t produce output of exactly the right type at exactly the right time, the system breaks down. Process improvement and innovation is for senior managers; observing the factory floor below from an air-conditioned room behind a wall of glass.

In the early 1800s the factory revolutionised the production of goods and heralded the onset of the industrial era. It raised millions of people from poverty and created countless jobs (and millionaires). It brought about a new kind of competition: one fought along the bottom line. The problem with the factory is that the race to the bottom is over: we hit it long ago. When every factory can produce widgets as cheaply as you can (or cheaper), your ability to differentiate lies elsewhere – it’s not enough just to be able to sell widgets cheaper than anyone else.

Luckily in the software product business we’re not factory workers. We encourage individual initative. We challenge our teams to help us improve our processes. We believe that innovation can (and should) come from anywhere.

Right?

If that’s true, why do we keep treating our teams like factories, and our people like factory workers? Why do companies push solutions to teams and expect them to be just assembled, (where possible by yesterday), without asking too many questions or making a fuss? Why do organisations rebuff any innovation or ideas that don’t come from their own team? Why do we incentivise teams and individuals on the quantity of output, and not the quality or impact?

It’s not enough to talk about supporting innovation and encouraging initiative… our daily working process has to support it too; otherwise, we’re just another factory.

The creatures, great and small, that exist today exist because they, and countless generations before them, each underwent tiny, microscopic changes that made each generation just a little better, stronger and more durable than the last. Each generation was a measured experiment, and every change was measured against the context of its environment. Those that worked were carried through to the following generations. Those that weren’t died out.

The more generations you have, the more opportunities you have to experiment, change and measure.

A horsefly or a flying fox cannot easily control how many generations they can produce in a given time. As a software product designer, though, you can.

Release early, release often. Measure. Repeat.

No animal is alive today that developed all its characteristics within one, three or even 100 generations.