April 11, 2018

The Most Important Framework For Product Leaders

This is the second post in a series about Product Management. Click here to read the first

In a 1997 developer conference Steve Jobs was confronted by an upset attendee. Steve’s entire response is great, but there’s about 60 seconds that really stand out to me:

This same idea — starting with the customer first and then working back to the technology — pops up in some early Jeff Bezos interviews as well:

As a result, this idea has become canonized as one of Amazon’s leadership principlesThese type of quotes can easily be brushed away as fluffy and high level, but I actually think it’s the most important framework a product leader should follow, and it can affect very specific parts of product management day to day.

Let me share a quick example.

Just last week I sat in a room with the engineer and designer I work most closely with at Wealthfront. We were debating 3 different options we had for an upcoming feature. Like most product conversations, each of us had slightly different ideas of how the feature should be implemented. In this case, we drifted quickly to discussing the pros and cons of each of the 3 options from an engineering perspective. Before long we were lost in the weeds of implementation and were leaning towards one of the three options solely because it was the smoothest to implement technically.

Fortunately we paused and revisited the original — and most important — question: what exactly is the job-to-be done here? What problem are we solving for the client? And what is the ideal experience?

After all, it’s only once you map out the ideal customer experience that you can effectively debate the pros and cons of an implementation.

So, the framework is:

Client → Design → Frontend → Backend

Start with the client. And work backwards.

Meaning, when building software you should:

  1. Define the ideal experience from the client perspective
  2. Then decide if that experience can be designed
  3. Then decide if the front-end engineers can put that experience into code
  4. Then decide if the back-end engineers can support it all

At Wealthfront, we’ve actually taken this a step further and for larger products we write the hypothetical blog post we could use on launch day, which outlines the experience we’re building (before we even start design).

If you can lay out the blog post before hand, it acts as a compass throughout the project to hold your team accountable to what you agreed you’d build up front.

And then, we do customer development.

But that’s the next post.