Every so often one of my articles seems to strike a chord, and this latest one on the difference between Product Teams and Feature Teams certainly seemed to do that. I am grateful for the very positive response. This morning I woke up to well over a hundred people who took the time to e-mail me a personal note of thanks, and often with follow-up questions.

As is my practice (and one I advocate for Product Managers generally), I like to consider the questions, and try to come up with a useful replies, and then share it so that everyone with that question, including in the future, can hopefully benefit from the dialog.

– You said that the designer is responsible for usability, and the engineers are responsible for feasibility, but is that all they are really there for?

This is extremely important, and something I know I need to write more about. I tried to capture some of this in the recent article on what is meant by true collaboration, but let me be very clear: design is about much more than just usability, and engineering is about much more than feasibility.

I will return to this point in a minute, but first I want to address the point I was trying to make.

If something ships from one of the companies I advise, and it is virtually unusable because of poor design (which as we all know occasionally does happen), you can bet I go directly to the designer and ask how this happened? It is absolutely on the designer to ensure this does not happen, so something went wrong.

Similarly, if the product ships and performance is terrible you can bet I go directly to the tech lead with the same question.

And most frequently of all, if something ships and the analytics show that it’s either not being bought or not being used, or it turns out that it violates some business constraint like compliance or privacy, you can bet I go right to the product manager with that question.

Realize that as an advisor I have no actual authority or control. But most of the teams know that my only goal is to help them become awesome, and these are prime learning opportunities and I am not going to pass them up.

So it’s critical on an empowered product team that we have the skills we need, and that these people are accountable for their work.

All that said, and back to the heart of the question, the way we come up with good solutions is with an intense give and take.

Designers often have insights based on deep understanding of our users and their behaviors that lead us in a different direction in terms of the problem we’re solving, or our approach to the problem. These insights will often have big impact on value, and indirect impacts on things like performance.

Similarly, strong engineers have deep insights into the enabling technology that often leads us to entirely different solutions to the problems we were assigned, often much better than anything the product manager, the designer or especially the customer could have imagined.

If I had to pick the one thing I love the most about the feeling of working in a truly empowered product team, it is the form of magic that happens when you have people that are a) motivated and b) skilled in their respective discipline – product, design and engineering – and they sit around a prototype or watch a user interact with our prototype, and the engineer points out new possibilities, and the designer points out different potential experiences, and the product manager weighs in with the sales or financial or privacy related implications, and after exploring a bunch of approaches, they find one that actually works – it’s valuable, it’s usable, it’s feasible and it’s viable.

So hopefully this makes clear that these are two different but related points. Yes, the designer is responsible for ensuring a usable product; and yes, the engineer is responsible for ensuring a feasible product; but coming up with that product requires their full range of skills.

– Can you summarize the differences between delivery, feature and product teams?

Delivery teams are not cross-functional (basically just developers plus a backlog administrator product owner), they are not focused on outcome (they are all about output), and they are not empowered (they are there to code and ship).

Feature teams usually are cross-functional (at least some form of designer and some form of product manager), but they are still all about output and not empowered.

Product teams are cross-functional, focused and measured by outcome, and empowered to come up with solutions that work.

– Can we have an empowered product team without a competent product manager?

In the article Empowered Product Teams I tried to describe the context that needs to be in place for empowered teams to happen, but one of the most critical pieces is that empowered product teams depend on having a competent product manager. Without this, the first issue is that the team is unlikely to be entrusted by management. The second issue is that the team won’t have the full set of skills it needs to come up with solutions to the problems they’ve been asked to solve. And I also believe that the lack of a competent product manager is the most common impediment to empowered product teams. Please note that I hold the product leader responsible for ensuring that every product team has a competent product manager.

– I’m still uncomfortable with the concept of the product manager as CEO of the product.

In the article I emphasize that the product manager is responsible for ensuring value and viability. That’s where this analogy comes from, and for those that have been a startup founder or CEO, you know that’s the heart of the job. And that’s why I continue to believe this is an important and relevant analogy. If that responsibility really freaks you out, consider the possibility that you may be more comfortable as the product manager of a feature team.

– Why would people be upset?

I spend much of my time in one form or another coaching product managers and product leaders, and I continue to encounter product managers that are not doing the job they need to do. I often ask them where they learned product, and they will often cite books, conferences, and training classes.

I’ve been very public in calling out the problem we have when product managers think that a CSPO class will teach them the product job, but it’s much worse than that.

There are many places today that offer “product management training,” and some even promote their “certification programs” but when I meet people that have attended many of these programs, and then when in disbelief I look at the curriculum, it becomes clear to me that they were being taught how to be a product manager of a feature team.

Over the past several years, as the importance of product has become more widely recognized, the education of product managers has turned into a relatively big business. And I knew that my article would essentially be calling bullshit on many of these programs.

I want to be clear, over the past few years there have been a few genuinely good books and conference talks that have come out, and I do what I can to promote these. But they are in the minority. I can’t even attend most product conferences because it physically pains me to hear what is often being advocated.

The other thing I was calling bullshit on, but admittedly this was a little less explicit in my note, was the idea that “we are all designers.” (As a side note, I find it amusing that you don’t hear teams saying “we are all developers”). On good product teams, we are not all designers. We are fortunate when we have one professional product designer. It is true that we all (stakeholders, product managers and engineers especially) bring constraints to the designer’s job, but good designers are all about solving for constraints.

– Is there any way to have true empowered product teams with SAFe?

I am certain the armies of consultants and trainers will argue yes just like they have with every other buzzword that sounds attractive, but I really don’t see how. It is a factory software model, and at the team level there isn’t even a true product manager or designer. It’s pure delivery teams. I wrote much more details on this in Revenge of the PMO.

– Why don’t you like to engage on Social Media/Twitter?

The truth is that there’s some things Twitter is really good for (such as notifying the people that might care that I have just written a new article). And there’s other things that I argue Twitter is awful for (such as discussing said article).

It happens every time. I publish an article, and people will often quote something they like, which is nice, but then others that haven’t read the article will respond to that quote, with none of the context, and things degenerate from there.

And I think the medium brings out the worst in people. The interaction model does not encourage the type of thought and dialog that is necessary to deal with hard problems (Twitter is actually what inspired the article on the need for product people to think deeply).

Moreover, even when I give in and I do occasionally engage, the next day, week, month, year, the same questions keep coming back up. Bottom line is that there’s just so much nonsense spouted on Twitter and I don’t see that changing.

Which is all to say, if you’d like an answer from me, please e-mail me directly.