The Software Product Management Blog

How to delight customers like Papa John’s Pizza

A recent trip to Papa John’s Pizza

Yesterday, I decided to order pizza from Papa John’s. It’s not typically my go-to choice, but its convenience is undeniable. I phoned in my order and was informed it would take about 20 minutes to prepare.

Surprisingly, when I arrived at the store just 12 minutes later, the employee at the counter immediately recognized me and my order, saying, “You’re here for the Pepperoni Pizza, right? It’s Joe, isn’t it? Just a couple more minutes.” This personal acknowledgment and the shorter-than-expected wait time genuinely impressed me.

Great 15 minute overview of the role of Product Owner

Henrik Kniberg,  Agile/Lean coach at Spotify & Lego gives a 15 minutes presentation on being a product owner. I love the way he condenses this information down into a digestable bit. https://youtu.be/502ILHjX9EE

Some key takeaways here.

1. Your agile teams should be cross functional.
2. Don’t get bogged down in manual regression testing. Invest in automated testing and continuous integration.
3. Every story needs at least one automated acceptance test and unit tests on the code.
4. Keep team morale high by using the velocity from earlier iterations or “yesterday’s weather” as an indicator of how much work a team is capable of taking on in a sprint.
5. Guessing the “value” of a story is hard to do, that’s ok though. Even when you are wrong the real benefit is in the conversations with the team.
6. Product ownership is all about communication which fits nicely with the agile manifesto.
7. Reduce risk by trying to acquire knowledge. Use UX prototypes, technical spikes, and experiments to gain that knowledge.
8. There should be a healthy tension between the building the right thing in building the thing right. This tension should be  between the product owner and the development team.

Add Agility to your Product Management Process

Agile is a software development process that focuses on delivering customer facing value in small iterations.

This article assumes that your development team works in Agile Scrum.

At my current company, the Product Management Process is what I would term Scrumfall. We do not build heavy Product Requirements Documents that we turn over to developers. Rather, we plan iterations while still maintaining an overall vision of what we think the final product should look like.

Rework Book Summary

The book Rework talks about the product development process at Basecamp. This is an outline of the book.

Lead the Field Book Summary

The book Lead the Field is one of those old school self-help books who’s advice is still applicable today. It focuses on developing yourself around serving others, developing a positive attitude, personal responsibility and goal setting. I wrote this outline so I could come back and visit the key points in the book. Have you read any good productivity books? I’d love you to take a moment to tell my your favorite in the comments.

Stop Treating Your Users Like Children

I spent about 15 minutes yesterday bulk deleting photos from Google+. Each time I clicked delete on a photo the computer so kindly asked me “Are you sure you want to do this?” I dutifully clicked “Yes”, as I’ve done thousands of times over the last 20+ years. Then, it hit me. Why am I still doing this? It’s 2013. If my computer were a sentient being and asked me to confirm every time I took some slightly dangerous action I would respond with something very sarcastic. “No, I don’t really want to do this. I just love clicking buttons.” Actually, I don’t. It made me feel a little like this guy. Why do we continue to think that we know our users better than they do? Why are we treating our users like children that we must protect because they aren’t able to protect themselves? Actually, that’s really not what’s going on. I’ve designed enough product to know that we’re not all sitting around thinking “Poor users, they just don’t know any better.” I think there is a much simpler explanation. We are lazy. Why are we lazy? It’s just so much easier to specify that a developer throw up a confirmation box then think through the problem. The thing is, it really doesn’t need much thought at all. The pattern for dealing with safely managing destructive actions has existed for almost as long as the computer. It’s called Undo. Ah, the Undo. You have saved my butt more times than I can count. And that’s exactly what you are there for. You are like Lindsay Lohan’s personal assistant. Never seen but always there to clean up the mess she makes. Why doesn’t every application implement Undo? Well, building an Undo system isn’t easy. It’s actually kind of a pain and you must plan for it up front. Despite that, every destructive action should have an Undo function. Why? Because your users have conditioned themselves to just blindly click on dialog boxes without reading them. Especially if they need to click many of them in a single session. They may just end up doing this. Confirmation boxes are a way for the product team to wash their hands of any responsibility for the actions their users take. Undo however, puts the responsibility back in the hands of the computer, the software team and the product owners. It’s harder to implement but provides a much better experience for people like myself.

Be Amazing

I recently went to a great BYOB restaurant that just opened in Philadelphia. A week later, they sent me this.

When was the last time you did something unexpected and awesome for your customers? Writing this card probably took the waitress 30 seconds to write. The impact for the business is priceless. I’ve already told a number of people about it (including you, the reader) and when I posted it on Facebook generated interest in the restaurant by people on my friend’s list.