Author: will

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

Posted on by will

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.

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

Posted on by will

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?

Driving innovation with agile: a short case study

Posted on by will

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.

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

Posted on by will

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.

Release it: now

Posted on by will

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!

GPS, turn-by-turn guidance and location-based services: what are they doing to my brain?

Posted on by will
Turn by turn GPS guidance on Ovi Maps on a motorcycle

There’s a motorcycle accessories store that I go to quite a lot. It’s quite a distance away – 10 kilometers through the city or so – but I like it because it has the best range and quite good prices. Anyway, I was there the other day buying some new touring pants, and as I got back on the bike to head home I noticed that the battery in my phone was dead. I have a GPS-holder mounted to the handlebar, and I use the GPS and Nokia’s Ovi Maps turn-by-turn navigation whenever I’m on the bike to get me around Berlin and Germany. Not this time, though – I was on my own.

I wasn’t worried: I must have driven this way 10 times before. Two blocks later I missed the first turn. After that, I stood for two minutes at another intersection wondering which way to go. Without my GPS I was sadly, sadly helpless.

I think I am losing the ability to remember the way to places. This is, I think, even impacting how easily I can find places.

To be more specific, I think I am losing my ability to process and remember the spatial relationships between places and things. This manifests itself in situations like the story above, where I found it difficult to get home without my GPS turned on spewing out directions at me. I also notice it when someone tries to explain verbally driving or walking directions to somewhere. “So you’ll wanna walk all the way down this street, then take the left by the big red warehouse, then the second left. After that you’ll come to a bridge…” After the second or third instruction, I’m lost.

It never used to be this way. 10 years ago I could look at a paper city map or street directory and then drive across town on my gut navigational feel. Coming home would be a breeze – I would know the way back without missing a beat. Now I’m so used to having someone tell me when to turn and how fast to drive (my GPS), I’m completely helpless without it.

What’s happened to me?

We hear a lot these days about how our relationship with memory, language and concentration is continually changing with our increased usage of and reliance on the internet. In his book The Shallows author Nicholas Carr explores how the prevalence of the internet as an information medium is actually changing the ways our brains work: our attention span is shorter, concentration more sporadic. We tend to speed-read and skim texts for keywords, and our consciousness seems now hardwired to navigate through hyperlinks: our attention flashes off on parallels based on keywords or themes in the text. Nearly no-one native to this, Carr predicts, will have the ability to read “Of war and peace”, for example. Their brain just won’t be able to process it: too long, too complex, too ‘heavy’.

I see this happening in my brain too; but based on my experience with my GPS what I am now really interested in is how the internet and mobile technologies, specifically location based services, impact and influence how we interact with places, and how they change our concept of spatial awareness.

To go back to the GPS example: I think relying on a GPS for so long has made me less reliant on my own conscious awareness, and subsequently my own memory. When you don’t have a small computer spurting out instructions at you you’re forced to, well, watch where you’re going. As you drive you observe street signs and landmarks, and you use these to make navigational decisions: you mentally build spatial connections between points in space around you as you ‘save’ the route in your mind. Driving home along the same route is easy because you have constructed a mental model of the way you’ve come. When you drive with turn-by-turn guidance, even when walking, you don’t do this so much. You disconnect from the scene; you’re not making navigational decisions anymore, you’re just doing what you’re told. Instead of a constant spatial feedback loop between you and the world, you are simply driving blind.

I think this changes the way you interact with the world around you in a very fundamental way. You become less the ‘driver’, in a sense, and more of a passenger. One thing I love about motorcycles as opposed to cars is that when you drive in a car, you’re constantly enclosed in a protective shell; this isolating bubble between you and the world. You move with this massive metal encasing through the scene, but you are not part of the scene. With a motorcycle, you’re not enclosed in anything (only your helmet). You can feel and smell the air around you. You’re part of the scene. Driving on GPS, I think, adds another layer to that bubble around you: you really are absent from the scene.

One could propose an experiment to attempt to measure the impact of relying on turn-by-turn guidance on how people interact with the world around them: take 12 participants, and split them into pairs. All pairs get the same navigational task: get from point A to point B in the city (the route should be unknown to all participants). Three pairs get a GPS with turn-by-turn guidance, three pairs get an old-fashioned street directory, and the last three pairs get nothing. At the end, quiz participants on how much they remember about the natural environment. How many Starbucks did they pass? What was the name of the main street? And so on. I predict the people navigating with no assistance would remember the most valuable details about the journey, and those navigating with GPS will struggle to remember much of anything meaningful at all.

I’m quite sure it goes much deeper than this, and that I’m just scratching the surface. For example, how do services like Foursquare or Facebook Places change how we interact with physical places? With the mass of place reviews, comments, checkins and other data available on the web, how is our perception of the quality of actual places effected? How does it change our concepts of what is good or bad, popular or unpopular, trendy or crappy? With the web on your desktop or mobile you have the ability to experience and interact with places other than the physical location you’re sitting in. What does that do for how you perceive the place?

As location-based services continue to mature and grow and penetrate our lives in deeper ways, understanding how users interact with products on an emotional and psychological level will be a key to building services that provide meaningful interactions. It’s also important to understand the effect these services have on our own concepts of spatial awareness and spatial cognitive processing: how do we interact with and feel about places, and how is this altered when we use these services? Understand this, and we can create experiences with meaning.

Tracking software bugs: keep the important ones; drop the rest

Posted on by will

In ancient neolithic farming communities, the size of the average tribe or village was about 150 people. That’s also about the size of most military units dating back to Roman antiquity and earlier, and it’s a number that features frequently in a variety of social antropological examples. It turns out, as Robin Dunbar popularised with his research from the early nineties, that 150 is about the number of individuals a single person can maintain a stable social relationship – that is, where you know who each of the people are, and how they relate to all the other people in the ‘network’. Malcom Gladwell talks about this extensively in his book Tipping Point.

The same is true, I think, for bugs in a software system. We have the ability to understand, process and relate to a relatively small and definitely finite backlist of bugs. I don’t know if 150 is exactly the number – and it would probably depend on the product and the type of bugs – but I think it’s close enough.

Many software projects have the tendency to track hundreds or even thousands of defects in long, long lists, maintained and even driven by complicated tools. Having so many bugs open makes it very difficult to see what’s truly important. With 800 bugs in the system, answering the question “what’s important today?” is hard.

You also need to deal with the fact that a large portion of these bugs won’t ever get fixed. They just won’t. Not because we don’t want to – at least not exclusively – but because a team can only fix so many bugs at a time. With such a large bug backlog the world around you changes quicker than you can fix all the defects, so many of them will end up being invalid or no longer relevant long before they could have been actually fixed. So was it worth tracking them in the first place?

Software development blogger Gojko Adzic thinks we should do away with bug tracking completely. I don’t think I would go so far: I think recording bugs in some kind of tool is necessary to see the major open problems with the software, allow scheduling of fixes and provides an important communication channel especially with offsite or offshore teams. I don’t think, however, that it is valuable or efficient to record every one of 1001 defects that were ever discovered.

Just like the stone-age farming villages, I think a team has the ability to deal with about 150 open defects at a time. Any more is just noise, and is probably going to cost (read: waste) you a lot of time in adminstration and error management that you won’t get a meaningful return on. What if you kept a record of the top 150 defects, and just dropped the rest? Just don’t record them?

The natural question to ask at this point is rightly “what are the top defects?”. The word ‘top’ is all about priority, and priority is a very context sensitive thing. Priority is relative to the vision of the product, the maturity of the software, the type of users and other product related factors; but priority is also relative to the priority of the other defects in the system. If your payment system is dropping payments or sending cash to the wrong accounts, then that layout issue on the invoice page is not going to be so important. But if the payments are processed perfectly and the layout problem is the only blemish, then it’s ‘top’ priority, relative to the other open issues.

Here’s a proposal: Define a minimum bar for defects; one that keeps your bug count at about 150. As the highest priority items are cleared up, then the priority of the next ones increases relatively – so you raise the bar in terms of which defects can be added. If your bug list grows over 150 (hopefully it doesn’t!) then drop the bar to stop recording stuff that you don’t have time or headspace to care about.

If you don’t care about it, then just drop it. If part of you cares but you have a hundred other more important things, then drop it too. Spending effort and time recording stuff that you’re team is not able to deal with just creates noise, consumes effort and makes it hard to see what’s important.

Let the team decide…

Posted on by will

In a typical agile development team a few hundred decisions get made every day, by everyone. Should we build this user story first or that one? Should I refactor this method now or do it later? Is this bug more important than that user story? Should I call that meeting for this week or next week?

Every decision that gets made, in the end, makes its mark on your product. Every decision impacts the team’s velocity or productivity, the product quality, the product features and the user experience.

If you’re planning a trip in your car, every decision you make along the way will impact where you arrive at, how long it takes and how many dents you have on your car when you get there. Do you want to get there quickly, or is time not so important? Do you want to avoid dirt roads, or do you prefer them? Is there a particular landmark you want to see on the way? You have an idea of what your journey will be like before you leave, and your decisions are based on that vision of your journey.

Back to the development team: every decision made will impact where and how you arrive at your destination. So the question is: does everyone in the team have the same vision of what your journey will look like?

One of the Product Owner’s most important roles is to define and communicate the product vision. The more the team understands and buys into the product vision, the more likely it is that each decision they make will lead the journey in the same direction you want to go.

Here’s a concrete example: a lot of POs spend a lot of time prioritising things: bugs, stories, meetings, etc. Many POs I know want to be involved in every decision the team makes. What makes one thing more important and/or urgent than another thing is all about vision and context. What would happen if the PO spent all the time she spent prioritising bugs on communicating the product vision? If the team understands the vision and context, then they should be able to make the right priority decision based on that vision and context.

Time invested making a single decision for the team has little return beyond the decision itself. Time invested in communicating vision will repay itself over and over with better decisions across the team, fewer bottlenecks and less wasted time.

Continuous delivery: release early, release often

Posted on by will

If you’re in the business of building a car, you only really only have one chance to get it right. Those years of research and development, trials, testing, marketing and building culminate in a single, big release – your car launch. You only have one chance because by the time your customers drive your car away from the lot, it’s too late to fix that overheating problem with the brakes, or add another 0.5L engine capacity. Shame.

Software used to be the same way. A software project would be analysed, specified, analysed again, specified again, built and re-built and finally, after months or years of development, would be burned onto a CD or floppy disks, put in a box and sent to a store. Before the internet getting updates to software was tricky. You had just one shot to get it right.

Today, we live in a very different software world – especially true for those of us working on web products. With the internet we have a delivery immediacy unlike any other product manufacturing system in the world. We can make a change today and our customers see it in their product, today. You can add a new feature today and start generating new revenue or new customer acquisitions tomorrow.

It goes further. You can release a feature today, and watch, in real time, how your users interact with it. If your key metrics go down, you can roll the feature back out. If there’s a problem, you can either fix it quickly, or roll it back. You have the power to interact directly with your customers immediately over the best channel possible: the product itself.

This is what continuous delivery is all about. It’s like a beautiful gift for any product developer, and I think not making the most of it is a waste of that gift. Release early, release often.

Better SCRUM User Stories: Connect the story with the real user value

Posted on by will

Everything you do to your product has a reason. There’s a reason that button is blue, or that message contains those words. There’s a reason you display that data or that notification.

Every reason is, at its heart, about the user.

This is why I like using user stories to talk about specific product developments and changes: writing stories reminds us that at every step of the way, everything you do is about your user. Every time you want to change something or add something, you need to understand ‘why’ – why are you adding what you’re adding, and why should the user care.

Connect the user story with the real user value. What the user wants. Not what you want, what marketing wants or what your boss wants – but what the user wants.

Here’s an example of a user story that came across my desk recently:

As a user, when I hover over search results in the search list, I want the pins on the map to change colour.

What’s wrong with this user story? Firstly, it’s a bit ambiguous – which pins?

As a user, when I over over search results in the search list, I want the pin representing that search result to change colour.

Ok, it’s a bit clearer. But is this what the user really wants? I don’t think users have a pin colour problem. What they have is a problem of identifying where the search result is located on the map. The colouring of the pins is a solution, which should be saved for the story specification or acceptance criteria. What the user wants, I think, is this:

As a user, I want to quickly understand where each search result is on the map relative to the other search results.

Clear. But why? Why does the user really want this? Understanding the why helps us understand how to solve their problem. That’s where the second, and often forgotten, part of the user story comes in: the ‘so that’ part:

As a user, I want to quickly understand where each search result is on the map relative to the other search results, so that I can get a feeling for where the place is relative to me or some other point.

Now we are at the core of what the user really wants, and we can go on to design a solution that solves this user problem. This process of story refinement gives us a better understanding of the true motives of the user: the ‘why’.

If you find that you’re looking at a user story that contains more problem specification than solution, keep refining until you get to the real user value; what the user really wants.