We met Marty Cagan at the Product Management + User Experience virtual conference through his talk Good to Great. After enjoying his insights on designing and building products we decided to ask him for an interview.
Here’s the first part of our conversation.
How Strong Should UX Research be while Defining a Product?
There are lots of schools of thought on this. And there are many good sources of product ideas.
What we hate is when the product team only uses one source.
Sometimes the only source of ideas are the executives. They just say what to build. Sometimes the engineers are a source of ideas. That happens to be one of my favorites.
User Research (UR) is also a great source of ideas. Some of those ideas come to user research by actually learning about your users. And some come from asking users. For example, focus groups. I personally hate those. So most teams I work with don’t use them.
Other times the User Research comes up with ideas by actually testing them on customers and seeing their response and their reactions.
This is my favorite use of User Research. But like I said, it’s not the only one.
Is There a Right Balance of These Sources of Ideas?
What we prefer is a model where there is a product person, a designer, and an engineer trying to solve a problem together.
The best solutions come when engineers are able to interact directly with users. Directly, face to face. Not over a Google Hangout or Skype.
Face to face.
What you don’t want happen is to have the product manager come up with requirements, and they give that to a designer to make it pretty. And then give that to the engineers to build it.
That’s waterfall, what I’ve just described. It’s also very constraining because the best solutions don’t come up that way.
Instead we want those three roles to work together to come up with the best solution to that particular business problem.
And this is something I try to say all the time, but most of the time the best solutions come when the engineers are able to interact directly with the users. Directly, face to face. Not over a Google Hangout or a Skype call. And definitely not through a document like User Stories.
Face to face.
Then the engineers can understand, deeply, the problem that really needs to be solved. They understand that users have to be able to use it. They often come up with the best solutions because they know what’s possible better than anybody else on the team.
Usually they know better than the product manager and they know better than the designer what’s possible. And so when you combine that knowledge of what’s possible with what’s needed, that’s when great products result.
Is There is a Balance in Rapidly Launching MVPs vs a Thoughtful Problem Discovery Phase?
It’s sort of neither.
The problem is the description. The way you are describing the use of an MVP, is not the purpose of an MVP.
A lot of teams make this mistake, launching a crappy product in the market fast. That’s not an MVP. That’s not at all what it is for. That’s not how it is used.
You absolutely should be validating.
We use something called MVP Experiments or MVP Tests to validate our designs before we build anything.
So absolutely you should be able to find those issues before you build anything from your developers.
But that’s a bigger topic, and it’s basically confusion over what an MVP is.
Is There a Right Way to Convince Stakeholders to Adopt UX in Their Methodology or Their Product Development Cycle?
When you are an agency it’s very hard to do design in the role we are talking about. Because the client thinks that they already know.
So part of it is an agency versus a product company.
In any case, one of the most important things about UX research is that it should never be done by the UX researchers alone. Never. It’s wasted if that’s what you do.
So you only do that with a product manager and the tech lead engineer because what happens, of course, is that the user researchers learn amazing things and then the rest of the team doesn’t understand and doesn’t believe it.
So we talk about shared learning, the UX researcher is only useful if there’s shared learning among the team.
You used the word stakeholders which may mean the rest of the team in your case, or normally it’s different executives.
But one way or another, the learning has to be shared. It doesn’t do anybody any good to have a researcher go off and interview customers and come back and write a report.
That’s a big waste of time and money.
Marty Cagan is the head of product at Silicon Valley Product Group. He has served as an executive responsible for defining and building products for companies including Hewlett-Packard, Netscape Communications, America Online, and eBay.
He’s also the author of Inspired: How to Create Products Customers Love published in 2008.
In part two we continue the conversation with Marty and talk about how a mature product team looks and how they’ve changed over time.
For More …
You can reach out to Misael Leon at [email protected].