Customer-focused product development

I've recently been watching video interviews of Jeff Bezos on Youtube. Over the years, I've spent way too much money on Amazon, yet I've never fully realized how customer-focused they are. This might be because I've never had to email or call them with support issues, which one could argue is a result of being customer-focused :)

For example, Bezos has an email inbox where customers can send him emails (you can read more here). While Bezos can't logistically handle support emails at this point, it helps him stay connected to the customer and their pain.

(above is an image of Bezos w/ Amazon's 1 millionth customer)

As I've watched these videos, I tried to come up with a simple way to think about being customer-focused from a product development perspective.

Typically, I will create Trello cards/specs with the following sections:

• Why (why are we working on this? Usually has a combination of anecdotal data paired w/ usage metrics)
• What (This section outlines what needs to be built)

As you might imagine, these cards are written for coworkers as the audience, but I don't think it's customer-focused enough. There's also some important info missing. Amazon has product managers "work backwards" and write a press release, which is an interesting idea, but I'm honestly not quite sure I'd do this in practice (at least without some external pressure).

Anyways, I'm starting to think about how I could improve my process, and this is a rough outline of some improvements I'm going to try and make in the future.

Target, Behavior, Pain, Painkiller (TBPP)

If you're thinking, "oh, here we go, another acronym", I'm going to try to make the rest of this post a bit more useful ;)

Target (Who)

First, you'll want to start off by outlining the target customer (i.e. - who is going to be using the feature or experiencing the benefit of your product/service). I'd argue that this should be the first thing mentioned, as it helps you frame the rest of the items based around the person the thing is built for. Clearly, the more specific, the better.

Behavior (When)

B.J Fogg talks about this in detail, but one of the biggest mistakes I've made over the years is underestimating how tough it is to change someone's behavior. Heck, I have trouble doing this myself.

Therefore, I'd argue that it's critical to identify & outline an existing behavior to "piggy-back" off. This can be a helpful exercise for the reasons mentioned below:

1. If you understand the frequency of a behavior occuring, you can estimate retention. For example, if I'm building a messenger app, and people communicate all-day long, it should measure effectiveness in terms of daily active users.
2. If you understand what behavior to tie to, you can be extremely targeted in how you message the benefits of a particular improvement.

Pain (Why)

The third point is that your improvement needs to be solving real customer pain.

"Do you know when you are trying to do $behavior and $painful_thing_occurs?

I may add more to this section as I think more about it, but it should be pretty self explanatory. A couple notes on this:

• I'd argue that entrepreneurs who build products to scratch their own itch and especially adept at this. They have experienced the pain they are trying to solve for.
• You also need to be hanging out with customers (phone/video/in-person) so you can understand the pain at a deeper level. A survey won't give you deep-enough insights here.

Painkiller (What)

Finally, you should describe how the improvement works. It seems like it should be broken down into two pieces:

1. The building blocks from an engineering/product development perspective (probably looks a bit like a user story)
2. The functional benefits that the improvements offers. What does the improvement enable for the customer? How does the improvement solve the pain outlined in the previous section? How will you know if you are successful in solving the pain?

In Conclusion

My past product development items focused on 2/4 of these sections. I'm hoping adding a bit more structure can improve the quality of work.

In addition, I'd like to add more color and improve upon these building blocks in the future. It's one thing to say you are customer-focused, but it's entirely different to have it permeate how you do your work on a daily basis.