Pointless product design: It’s not about velocity

I’ve started to wrap up some ideas for a blog post when I had a conversation with Jeff Patton about product design, while he were in Brazil with Globo.com doing some consulting work. Patton’s specialty is on product design, and he has some pretty good ideas about how to handle it – I’ll probably talk a little more about his ideas on another post – and I kind of had an epiphany when I saw the following tweet by Jeff:

Looking forward to the time when people use agile development to build great products, not just deliver dumb stuff faster – Jeff Patton

This instantaneously reminded me of a StackOverflow podcast I’ve listened to a few months ago. This was a remarkable podcast, because they had Uncle Bob Martin as a special guest. In the previous podCast of the series (podCast 40), Jeff Atwood made a statement that caused some discomfort between Uncle Bob and themselves, so they invited Uncle Bob to the next podCast to clear things out, but that’s not the point.

The point is when Atwood says (just search for “wordpress” on the transcript and you’ll find it):

So, to me the root issue is if you deliver a product, a software product, that nobody likes or wants to use, it really doesn’t matter how high quality your code is. That’s really the bottom line. And I think I’ve learned this from WordPress, because WordPress is a great, it’s a fantastic tool, but the code is the worst code you can possibly imagine. First of all it’s written in PHP which is already a problem right, on top of that it’s crazy PHP, like it’ll melt your brain if you look at it too long.

I can’t help but agree with Atwood’s statement. What I understood is that he said that the overall product quality is as important as the code quality underneath it – and even if you have a crappy code underneath, and a great product emerging from it, you could get away with it. This doesn’t mean that you have a license to produce crappy code if you’ve got a good product – it does mean that you have to pay attention not only to the technical part of the thing, and make an effort to design great products implemented with great code.

One trap that I see many people in the agile world falling for is not worrying at all about product quality, which take us back to Patton’s tweet. I see too much focus on the technical details (as of in engineering), and on the agile “process” or “framework”, leaving the Product Owner behind, alone in the dark, to “define the product”. It’s one major cause of many project’s failures. Agile is not only about creating great code, nor about following a “process” or “framework”. It’s about creating great products, collaboratively, as a team. This means a shared backlog, shared product ownership, shared vision.

What bring us to the point of velocity, as in throughput of the team. Your product will not be better if you deliver just as many features as you could, as fast as hell. In order to deliver a great product, you don’t need to go faster – you need to go well. It’s good to remember that Pareto’s principle applies very strongly in software development – 20% of our product features get to be used by our users for 80% of the application usage time. So, why don’t heavily invest in having this 20% of features mastered, so you can guarantee a freaking great experience for your users 80% of the time?

When I was talking about this with Marcos Pereira, he brought into light a fairly old post from Kathy Sierra, on Kathy’s Creating Passionate Users blog. In her blog post, she presents the Pareto Principle in a very good way, talking about The Design of Everyday Things, and how a simple car stereo got so bloated with features that it’s almost impossible to use it without looking into the manual. This is exactly what I mean, and we’ve seen greater successes of simplification out on the real world. Look at the iPod’s user experience. It’s easy, intuitive, and you barely have to look to the manual to use it. The advanced functionalities are still there, but you don’t need to bother with them just to listen to your music. MP3 players have been around for a long time, but only after Apple “re-invented” the iPod, this market kicked-off.

In order to achieve this excellence level in Product Design, you need to think differently when it comes to backlog prioritization. I’ve seen it work in a few Product Backlogs in Globo.com. Instead of having a huge pile of histories on your product backlog, precisely divided in order to provide incremental delivery, you just focus on the main functionality, and rank it according to the following experience-driven scale (this is just an example – please feel free to add/modify/build yours from scratch):

• Ashamed of (the functionality exists, but doesn’t have a good experience. The team would be ashamed to present this piece of the software to an end-user).
• Hum.. just fair. (the functionality exists, and is fairly usable. Depending on the importance of this functionality, it might be enough for a beta tester to try it out).
• Enough (the functionality is usable. It’s just enough for production release, and most of the users will like it.)
• The best! (the functionality is so good that our users just love it. This is the time to add the extra piece of functionality that will turn your users in addicted monkeys. Nah, just kidding! But this is the idea 🙂 – this functionality is now a master piece of work!).

Now would be a good time for an example…

So, for instance, let’s take a Webmail application as an example. One functionality that is in the 20% group that gets used 80% of the time is the  “send email” functionality. Your team could deliver it incrementally and iteratively, by first creating it and being ashamed of it (ex. very basic send email – no BCC, no CC, no WYSIWYG editor). In a future iteration, your team goal would be to make the “send email” functionality just fair for usage (ex. add a WYSIWYG editor, add bcc and cc fields) – and then release to your beta users. On the next iteration, the team would add some more of this functionality, in this case the ability to send a message with levels of priority, or add labels, of whatever your team think that will make a difference to the end user.

This kind of backlog prioritization cannot be done if the team doesn’t feel the ownership of the product, or if the Product Owner doesn’t share the backlog with the team. The end result of this is a natural, user-driven prioritization, when people will start to take into account that maybe it’s best to invest on a new feature until it’s Enough than to make this functionality the bestest best since the beginning, and have other functionalities worked at the same time, incrementally improving them all.

This will basically help you do more of what matters, and less of what doesn’t matter a lot in the long run. Start with a beginner’s mind, and start building best products and making your users happier!