SCRUM User Stories: As a User, NOT As a Manager

The success or failure of a piece of software, or any product for that matter, is how well its users are satisfied, and how well it solves their needs. In the world of web software, adding functionality is rarely the differentiating factor that will lead to the winning product. More likely the winner is the product that solves the user’s problem in the simplest, easiest and most delightful way.

In other words, product design is all about the user: solving their needs the best way possible. Every single line of code you write should help the user solve their needs better and easier…

… which is why I am often confused when I see user stories like “As a product owner, I want…” or “As a manager, I want…” Or worse still: “As a data centre, I want…”

Who ever asked a data centre what it wants?

User stories start with “As a user…” for a reason: the process of writing a clear sentence that starts with “As a user” forces you, with each product decision you make, to consider and understand how what you are about to do allows you to solve the user’s needs in a better, more efficient way. If you can’t do that, then you have to question why you are adding this user story at all.

Avoid stories that start with anything other than “As a user”. That’s why they’re called User stories. If you can’t work out what a user gets out of the deal, it probably isn’t worth it.

Posted in Agile, Scrum, Software management | Tagged | 2 Comments

Move fast

The world moves fast. Your competitors move fast with it.

Users move fast, too. Users are more fickle than ever before. This month’s UK WIRED magazine rated Twitter as “tired”. This for a service that’s only five years old with a still-growing userbase. Ouch!

In the world of web products, building and releasing beautiful and delightful products and user experiences is only half of the battle. The other half is winning (and keeping) your userbase. Your product could have a net promoter score of +80, but if it still only has 10 users, is it really successful? If you build it, they won’t necessarily come.

Users want stability and reliability. Once they have settled in to a product that solves a particular need, it’s that much harder to get their attention to yours. At the same time, and perhaps contradictorily (who said human beings were simple?), users also crave the new. New updates, new versions, new features. News, blogs and social channels thrive on the new.

The web has sped up business dramatically and continues to speed up software product innovation. It’s a race to the bottom – at some point we won’t be able to go much quicker – but we’re not at the end of that race just yet. The strategy to compete in this space, I think, has two major components:

1. Work fast. Build fast, iterate fast: improve fast.
2. Be ready for when we hit the bottom. When we can’t go faster, on what track will the next race be run? Which race can you win?

Important note: fast doesn’t mean chaotic and unplanned.

Posted in Agile, Continuous delivery, Product Design, Product Management, Software management | Tagged , , | Leave a comment

Classic product management wisdom from one of the fathers of industrial design

In 1955 Henry Dreyfuss, one of the most influential industrial designers of the 20th century, in his book “Designing for People” wrote the following :

“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.”

Clearly this sentiment is as relevant for designers today as it was 55 years ago when it was written. It’s also interesting how the description rings true for product managers. In fact, I couldn’t have come up with a better description of the modern-day product manager if I tried.

Product management is more than schedules, roadmaps and powerpoints. Product management is about identifying a need and building a solution. It’s about understanding people (users) and understanding “how things are made”.

Designing for People - Henry Dreyfuss - Many hats sketch“From the book Designing for People – Dreyfuss’s sketch of the multi-skilled designer.
Posted in Product Design, Product Management | Tagged , , , , | Leave a comment

The most important career skill for this century: fixing what’s broken

Companies are a complicated beasts. Reporting lines, structures, process, heirarchy, politics… finding your way through the corporate maze and working out how to get things done and ship meaningful work can be tough.

If you look around in any company, I’m sure you’ll see things that don’t make sense. You’ll see ineffective managers and inefficient processes. You’ll see failures and you’ll see waste.

When you look attentively and deliberately at the world around you, you will see so many things that are broken or could be improved. The more you look, the better you will become at seeing. You’ll undoubtedly see more things than you’ll ever have the time to work on.

Your first responsibility is to look. Your second responsibility is to act. If you see something broken, try to fix it – even if it’s not your job. Avoid ignoring the problem or building a complex workaround – try to fix the problem at it’s root.

If you really can’t fix the problem, then accept it as a constraint and move on. Leverage the constraint; use it to help you ship meaningful work.

In a world where software continues to automate generic factory-like work the most valuable skill becomes the ability to solve new and evolving problems… So if you have a choice between staring at your email inbox and fixing something that’s broken, what do you do?

Posted in Career, Life at work | Tagged , , | Leave a comment

Driving innovation with agile: a short case study

A prototype of the first mouse

We all know the story – but it’s still remarkably easy to forget that some of the most influential innovations in the field of personal computing, including the mouse, the laser printer, computer generated bitmap graphics and the graphical user interface, were not invented by Microsoft or Apple, but by a small research centre in the Valley called the Xerox Palo Alto Research Center (PARC).

Of course, part of the reason we all forget is that PARC are equally famous for fumbling the future, as was written in 1988, and not managing to capitalise on these innovations. For the next 20 years PARC was largely ridiculed and mostly forgotten.

Flash forward to today, and PARC, now spun off as an independent subsidiary of Xerox, is back in the big leagues and delivering a huge amount of innovations to tech startups, corporations and even the U.S. Government. Harvard Business Review have posted an interesting article on the HBR Blog about the secret to their reinventing themselves. One point stood out to me like a beacon:

Part of the magic lies in the current business model which, as Lawrence Lee, director of strategy, explained to us, relies on partnering closely with customers, inventing a minimally viable product, and collaboratively iterating from there, based on market feedback.

This is what agile, and continuous delivery, is all about: get your innovations into the hands of the customer as soon as possible, and iterate based on real feedback. It’s about “inventing a minimally viable product”, and using real feedback, real customers, real interactions, to make the next decisions that impact what your product ends up like and in what direction it goes.

Interestingly, the other ingredients to their success were People, Collaboration and Communication.

Now consider the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The basic principles that helped PARC reinvent themselves once again into a successful innovation house are the same principles that drive agile software projects. Even if they didn’t use the word ‘agile’, the engineers at PARC are living the Agile Manifesto every day.

Posted in Agile, Continuous delivery | Tagged , , , , , | Leave a comment

User testing: an input to innovation, not a source of it

Benz “Velo” model (1894)

It’s hard to imagine a life without cars. Before the automobile was invented getting around was a costly and particularly time-consuming business. That quick drive to the hardware store that takes 15 minutes in the car might have taken several hours on horseback, or an entire day in a horse-drawn carriage. Looking back, it’s hard to imagine how anyone was motivated to move anywhere at all. (In fact, most people didn’t… before the automobile, and particularly before rail, it wasn’t uncommon for people to spend their whole lives in the town they were born in.)

So if you could go back roughly 130 years and show someone the automobile, they would love it, right? If you asked someone the question, “is this product something you would buy and use?” the answer would be a resounding “Yes!”. Right?

Well… not really. When the first automobiles rolled onto the streets in the late 1800’s, they were met with skepticism and fear. People (and horses) were terrified by the noise, and people just couldn’t understand why anyone would need to go so far or why they would be in such a hurry. In other words, the automobile was an invention for a problem no-one had. Or, to be potentially more precise, a problem they didn’t yet know they had.

If you had shown concept drawings of the automobile to a focus group in 1885, or a working prototype to a user testing group, you might have walked away thinking that you’d be better off working on putting a clock radio* in your range of horse-drawn carriages.

The point is, you can’t expect users to know what they want. Innovation doesn’t come from asking a customer focus group “what products do you want that haven’t been invented yet?”

The iPad was a solution to a problem that no-one really had. Companies and products that innovate are successful because they can predict user behaviour before the users go anywhere near it. They are also good at convincing (selling) users that they have problems that their products can solve. No-one had a standing-motorised-transport-problem before the Segway was invented, but the company behind the gyroscopically controlled contraptions still managed to ship over 50,000 units by 2009.

We recently ran some early user testing on a product concept that we are working on. Based on the results, some members of our team were hugely disheartened: most of our test users, when asked if they could imagine them getting major value out of one of our concept’s major use cases, said “no”. Some thought we should go back to the drawing board. I think they missed the point…

User testing is one input to product design; one of many. Getting the input and responses of potential users early in the design process is crucial; however to make the results really meaningful you need to interpret them in relation to the test user’s context… and sometimes I think you just need to take the responses with a grain of salt. You also, I think, need to understand that innovation often comes from having the courage to challenge users on what they think they need and what problems they have.

* I’m of course aware that there were no clock radios in 1885. The first transistor radio wasn’t invented until 1954 by Sony in Japan. Call it poetic licence.

Posted in Product Design, Product Management, Software management | Tagged , , | Leave a comment

Release it: now

Release your software to real users as early as possible.

Building software for years without ever releasing any of it is like working in a kitchen and letting the food go cold and mouldy before serving it up.

Building software is a collaborative process – not just amongst you and your colleagues – or between you and your partners – but between you and your users. Feedback from real users helps you guide the future of your product and your immediate investments. It helps you prioritise and optimise. Making product decisions without real user feedback is quite often, I think, guesswork. Yes, it’s (hopefully) educated guesswork – but it’s guesswork all the same.

You can learn a lot from user testing and user research prior to release – and there’s no way you would want to skip these steps – but nothing can replace the feedback you get when real people use your product, with real use cases, under real load.

If you see that you’ve been sitting on the latest version of your product for months without any of it hitting a user, or if you find yourself wanting to squeeze “just one more feature” in before you drop the release, then stop and think: can I give my users meaningful, measurable value with this release? If so, then release it. Now!

Posted in Agile, Continuous delivery, Product Management, Software management | Tagged , | 3 Comments