Yin, Yang, The What, and The How

by Bill Bliss on April 13, 2011

in Alleged Wisdom,Featured

Cindy Alvarez wrote a great article this week entitled 5 Reasons Why You Have No Credibility with Engineering. Number one on the list is something that every software developer and product manager can relate to: You over-specify the solution, referring to how product managers sometimes describe the solution instead of focusing on defining the problem. I winced a little, because I’ve been there.

One of the comments on Cindy’s article also resonated with me, from Jason Yip:

I would say that the #1 reason would be that the product manager and engineering team are not actually working together as closely as they could. When engineering team members are involved in the exploration of customers, when product managers are involved in the day-to-day of product engineering, a lot of these problems tend to take care of themselves.

Jason is completely right. So is Cindy. So what can we do to get product managers and software developers to work more closely with each other while still keeping roles and responsibilities clear?

One way is to be on the same page with what I call The What and The How:

  • The What. What the product or feature does, including its design (what it looks like and the way a user interacts with it)
  • The How. How the product or feature actually works (the implementation)

I’ve found that in many companies, people subconsciously think about it like this:

(I’ve found this even in Agile shops, which is a little ironic because it’s a pretty waterfall-ish way of looking at it.) Of course, when you think about it this way, it’s easy to focus on the distinction between product management and development, because it’s generally understood that The What is the responsibility of product management, and The How is the responsibility of development.

The problem is that picture is wrong. It implies that The What can be separated from The How. The reality is more like this:

What a product does—and in particular how well the product works—is interconnected and interdependent with how it’s implemented: whether you think about it that way or not. Now, I don’t think that’s a claim that can be proven scientifically, so I’m not even going to try. But consider this: if The What and The How weren’t so deeply intertwined, wouldn’t it would be a lot easier to outsource product development? Wouldn’t it be easier to for competitors to clone great products such as the iPad? Wouldn’t it be easier to integrate design and product management into Agile?

Great product teams focus on the boundary between The What and The How. In practice, this means two things:

  • Knowing where to draw the line. Any product manager can think of cases where The How matters (Cindy listed a few). Any developer can think of cases where The What did change or should have changed because of The How. The key is to choose the boundary intentionally…which you can only do if product managers and developers talk to each other. A lot.
  • Making the line as smooth as possible. In the picture, the boundary is smooth. In practice, it’s always a little jagged. Jagged edges occur when the implementation doesn’t quite match the requirements and vice versa. With great products built by great teams, the line looks smooth, at least from a distance, because they worked closely together to ensure it did. It doesn’t happen by accident.

The takeaway? Great product teams understand what a product does and how it works are like the yin and yang in Chinese philosophy: they are interconnected and interdependent. They focus on the boundary between the two.

Tweet this: @bill_bliss New post: Yin, Yang, The What, and The How http://wp.me/p1pkik-6d #prodmgmt #agile

{ 2 comments… read them below or add one }

John Halloran April 14, 2011 at 6:54 am

This is a really great way of expressing it, Bill. There are plenty of angles to be explored here, but one that jumps immediately to mind is this: in a well-functioning organization, the ‘line’ seems likely to shift somewhat during the lifecycle. I.E. engineering will be much more involved in the ‘what’ in early phases, but less so as the offering or release matures.

This natural shifting has some interesting implications for the product manager, who understands the dynamic, and needs to tune communication activities through the lifecycle in order to keep balance.

Thanks for a great post.


Bill Bliss April 14, 2011 at 7:02 am

That’s a really good point John – I didn’t think of that case, but you are absolutely right, on both fronts.


Leave a Comment

Previous post: