We met Jeff Gothelf, Organizational Designer, at a virtual conference on product design. We had the chance to talk to him about UX teams and building user-friendly software products.

This is the second of two parts. If you missed it, you can read part one.

Jeff gave a presentation called, There’s No such Thing as UX Strategy at the Product Management + User Experience Conferences. Afterwards we got together with him again for this conversation.

What Is the Future of Design Teams as We Know Them?

I think that there will always be room for design teams.

Think about the Spotify model. They’ve got dedicated designers on cross functional product teams. But there is also a design team, and that design team is responsible for professional development, for support, for inspiration, and for discussion of nerdy design things that nobody else wants to talk about. There’s always going to be room for that. I just think that if you’re trying to staff projects from a central design team, like a central agency, I have personally seen that model fail.

Most companies have seen that model fail ultimately, or they’re continuing to try to make it work. The lack of UX strategy as its own unique thing doesn’t negate the need for UX and UX designers. It just means that we have to take a holistic point of view. And to do that, you need to be part of a cross functional team where all those points of view are regularly available and discussed.

Again, periodically the teams come together to a design meeting, to review, to share best practices, to talk about what they learned, to build pattern libraries, whatever it is. But I think that the “internal agency” is ultimately an anti-pattern.

Can You Foresee How These Product Teams Are Going to Look Like in the Near Future?

I think the future of product teams is made of product design and engineering, and supporting disciplines. I say design as an umbrella term to really cover all the various forms of design from UX to visual to interaction to content, all the components of the presentation layer from the development, etc. Also product management and engineering at the very least and then follow it up with support from whoever else the team needs to be successful.

For example, if you worked in a medical services company you may need subject matter experts from the medical field to help you to do your job well. If you’re a financial services firm you may need access to bankers to help you do your job well. I think that’s the key, the point is to make those cross functional teams as autonomous, and empowered, as possible. So give them these outcomes to achieve, these behavior based goals, and then let them figure out how to best get there.

Given a Reduced Amount of Time for a Sprint, What’s the Best Way to Assess What’s the Right UX Research Method?

The way that I advise teams is to sit down and decide what is the most important thing you need to learn next. Based on that, the next question is what is the least amount of work that you need to do to learn that. Then that usually leads to some kind of activity.

The least amount of work that you can do to learn that is not lazy, it’s simply an opportunity to do just enough work to take the next step. That’s ultimately the key here, the key is not to do more than you need to. The key is to do just enough to move the conversation forward.

So, those are the two questions that I always ponder: what’s the most important, and the interesting thing to do. When you have those conversations with teams there’s usually a broad spectrum of answers to the question, “What’s the most important thing you need to learn first, or next?” It’s amazing how as teams get better at answering that question, the scope of the answer to that question decreases.

For example, let’s say you were building a new financial service, or just a new subscription product, and you ask the team, “What’s the most important thing you need to learn next?” And they say, “Well, we need to learn if people will pay for our service.” That’s not actually true.

The most important thing you need to find out is whether or not there is a need for your service. Then whether people will actually value a solution to that need, and so forth. You can move your way through the conversation, all the while increasing the amount of evidence that you have for investing further in your idea, in your feature, in your product, etc.

Is There a Right Balance between Rapid-launching of MVPs vs a Thoughtful Problem Discovery Phase?

Yes. There has to be a balance. At some point you have to ship software. There’s a balance of saying, “We have enough information to take a risk and build something.” That is completely contextual to your business. I would recommend that you build something fairly quickly. Does that mean code? Not always.

Sometimes it’s a prototype, sometimes it’s a Wizard of Oz MVP type of thing, where you’re faking a service. It feels like a real service but there’s not a real service there. The goal is to get your potential customers experiencing what it might be like to use this product or service, and to give you some feedback quickly. The sooner that you get that feedback, you can determine whether you should actually invest—I think that’s the key.

Finding that balance is difficult. It’s really difficult because we like to believe that our research activities will yield very clear results. The reality is that they often don’t. Sometimes you’ll get some feedback from experiments from a research study that says that the audience is split. We could go option A, or option B.

I think at that point you really need to double down. You take a risk and see what happens. The thing to remember is that when you take that risk, it’s a small risk. You’re not just deploying everything down that one path, you’re deploying another small step. If it continues to work well, terrific.

If it doesn’t, it’s OK to go back and try the idea that you chose not to work on. That’s the key, people feel like, “‘Well, we made a decision, now we have to do it that way.”

And that’s not true, you don’t have to.

About Jeff


Jeff Gothelf is an accomplished teacher, workshop leader, and public speaker. In 2012 he founded Proof, a lean product design innovation studio in New York City. Later acquired by Neo Innovation Labs.

In 2013 he co-authored (with Josh Seiden) Lean UX: Applying Lean Principles to Improve User Experiences. His next book will be called Sense and Respond and will be out in late 2016.

Interactive Transcript

If you’d like to hear to our actual conversation with Jeff Gothelf, you can listen to this interactive transcript.

For More …

You can reach out to Misael Leon at [email protected].