Dan Olsen on Becoming a Lean Product Ninja

Dan OlsenDan Olsen has traveled the country teaching people how to become "Product Ninjas" by introducing Lean product development processes into their organizations. He also consults with startups on how to create better products and processes. I was fortunate enough to get some time with him recently to discuss his insights and what he's excited about right now.

Dan's recipe for building great products

We started out by going through some of the concepts he covers in his presentation "Building Great Products the Lean Startup Way," which you can watch below. (You can also see a similar version without audio here.)

Product-market fit

When talking about his presentation, Dan started off by summing it up this way: "my talks are about distinguishing problem space vs. solution space and achieving product-market fit."

He says that determining what problem to solve is key and that the problem is conditional on identifying a target customer. You need to have someone who not only has that problem but is willing to pay you to help them solve it.

"You put your product out there, it's like bait on a hook. It's going to attract a certain kind of fish."

He likens product strategies to fishing. He says, "you put your product out there, it's like bait on a hook. It's going to attract a certain kind of fish." In one model, you may have bait that you know attracts the type of fish you've determined that you're going after, but "sometimes you throw your hook in the water without a good sense of what you're fishing for." In this case you end up with whatever fish responds to the kind of bait you have.

This latter model is growing in popularity with the greater availability of data and analytics that allow you to more easily discover who's buying your products, and the rise of concepts like Lean and Agile, where iteration cycles can be shorter and product teams can respond more quickly to feedback.

He cautions that just because you may have a lot of data about your customers doesn't mean that you really know them. You can get all kinds of demographics on gender, location, age, etc., but it can be hard for this data to be actionable. He thinks that talking to customers (the "fish" you've caught) directly can be greatly valuable. What works in practice, he says, is "you see what you catch and you talk to them... and you discover what they have in common." This helps you begin to learn which people value the benefits that your product provides relative to the other products out there.

He describes this as a kind of circular logic, yet it works. You put your product out there with a specific problem in mind that you're solving. Then you see who buys it and you iterate on your product by learning more about the problems those customers face, which may or may not be in the problem set you initially set out to solve.

Now that you've learned more about which customers are interested in buying your product, you can stop targeting the ones who aren't.

A consequence of this is that some attributes of the customer demographic that you had in mind initially will inevitably "fall out", meaning that they're no longer primary audience attributes for your product and shouldn't be targeted going forward. This completes the cycle; now that you've learned more about which customers are interested in buying your product, you can stop targeting the ones who aren't.

Making the leap to solution space

Once you've established a clearer idea of your target audience and their problem space, it's time to focus on the solution space, which is where design and wireframing come into play. Dan says, "design is the creative leap from problem space to solution space."

A lot has changed in this world as well. When consulting with or talking to Product Managers he will start by talking about the traditional role of a PM, saying that the old model was that a PM would write a large Product Requirements Document (PRD) and then hand it off to the development team. He says that PMs used to get by "living in [Microsoft] Word" but that's no longer the case.

Many companies are going Agile, writing user stories, and following the Lean Startup methodology. Yet that alone doesn't lead to better solutions. "When you have dozens of user stories it's hard to get a sense of what the heck is going on."

He says that wireframes and a UX presence in the organization help "tie it all together."

"You give developers text, what do you expect to get? You're going to get whatever UI they come up with. And that's not their fault."

When talking to PMs his advice is to hire a UX designer if they haven't already and to start including wireframing in the design process. In the old model of PRDs and similar documents, "you give developers text, what do you expect to get? You're going to get whatever UI they come up with. And that's not their fault."

In place of the PRD in modern organizations he says that now "the combination of annotated wireframes or mockups plus the user stories become the spec."

Dan's model of a "fully staffed product team" includes PM, UX design (specializing in information architecture and interaction design), visual design, and development (front end and back end). He says, "that's the continuum of skills you need" and, ideally, each role knows a little bit about the adjacent ones to facilitate communication between them.

He calls this the product A Team.

a-teamCredit: "How to Be a UX Design Army of One"

Having a UX designer on your team doesn't mean that you no longer need to create wireframes.

Finally, Dan advises that having a UX designer on your team doesn't mean that you no longer need to create wireframes. Wireframes are essential as a means of communicating design ideas to other members of the team. He believes that wireframes are so important because they're usually the first non-textual design artifact that's created. Without wireframes, "you and I can violently agree on 10 user stories, but in your head you're thinking of one UI and I'm thinking of a completely different UI."

The current state of UX

We then shifted gears because I wanted to hear his thoughts on the state of UX design as someone who is steeped in it every day. I asked him about the recent spike in interest in "Customer Experience" as well as his observations on the maturity of UX in the organizations he sees.

On "Customer Experience" (CX)

Dan confirmed what I had observed casually, that User Experience discussions are now being broadened to include the entire Customer Experience. He said, "CX is growing in prevalence in job titles" and mentioned that he has seen positions advertised with titles like "Chief Customer Officer" and "VP of CX".

I asked him why he felt this was happening.

Dan said, "I think the bar is being raised" because customer expectations are higher and there is more competition across all aspects of the experience. He feels that this is true for both for user experience and customer experience overall.

Customer expectations are higher and there is more competition across all aspects of the experience.

Additionally, you can no longer just release a product and leave it at that. "You need to get feedback and see what's going on."

He continued by saying that customer experience can mean different things based on the industry. A small app developer, for example, may not really think in terms of "CX" because for that developer "the Venn diagram of what is CX that is not UX is small," but large companies that sell products in stores have so many more customer touchpoints, including retail, call centers, etc. These companies are likely to think about customer experience more broadly.

For these large companies, aggregating data across disparate experience channels can be a huge challenge. But having a voice-of-the-customer channel can be incredibly powerful. When somebody first catalogs the customer's experience across the different touchpoints it can be a shock, he says, because they are so different. "Usually when you do that first audit it's pretty eye-opening."

On design maturity in the real world

Finally, I asked Dan about the state of User Experience across the organizations he talks to and works with. He explained to me why he is such a big fan of wireframing, and why it's the first thing he recommends to most of his clients, by talking about the different levels of his design maturity model.

ux-design-gapCredit: "How to Be a UX Design Army of One"

Dan talks about the UX design gap in many organizations. "The most common situation you see are teams that only have developers, there's not even a product person. There's certainly no designer." The next level up is developers and a PM. In both cases they are probably not creating wireframes, so you get a lot of different ideas about what the product is going to be. He continued, "even when you add a visual designer, they go straight to Illustrator and Photoshop," so the communication barriers during the development process still exist.

"The most common situation you see are teams that only have developers, there's not even a product person. There's certainly no designer."

He said that frequently, "it's not until you get a UI designer or a PM who knows [Balsamiq Mockups] that you get wireframing as part of the process." This is one of the reasons why he calls Balsamiq Mockups "the best $79 you'll spend," because wireframing is something that anyone can do, but that many small or new organizations don't do or even know about.

Even within teams that have a UX designer, he said that many companies are far from mature. I mentioned the UX blogs I follow and how they can make it seem like everyone is really pushing the envelope in UX. He said that's not the norm, saying, "it's a typical bell curve. You're looking at the 3 sigma people. Those are the people writing about it and debating the finer points of doing it this way vs. that way."

He's observed the same thing for programming languages and technology choices. The business or idea people he talks to just want their idea executed on, they don't necessarily know or even care about the technology used to build it. He told me that for a lot of non-technical founders, the decision about which language to use should be driven more by practical support for it, the ecosystem around it, and the availability of developers who know it.

It's a great time to be building digital products

We wrapped up our conversation by discussing what Dan is most excited about right now. He told me, as someone who has been creating software for 20 years that now is a great time to be building products because of the tools that are available. These tools not only optimize workflows for specialists, they also mean that for small teams, you don't have to be an expert in everything.

There are a lot of tools available now, and many of them are very good. He said, "good tools are popping up left and right... Within the A/B testing space alone, there's all this competition." He continued, "just like customers benefit when there's competition in a product market, product builders benefit when there are a lot of choices and competition in the tools market."

"Just like customers benefit when there's competition in a product market, product builders benefit when there are a lot of choices and competition in the tools market."

Comparing today to the old ways, he said, "I've been there when Marketing is asking Dev to change some HTML. Marketing is frustrated that their little HTML change request has to go through the normal product pipeline - get prioritized, who knows when it's going to get launched - and Dev is frustrated, they're like, 'Are you serious? I want to be coding cool algorithms, I don't want to be changing HTML. That's not even coding'."

But with today's tools, like modern CMS systems, "now, all of a sudden, Marketing can make those changes. Everyone is happy."

He also mentioned the trend towards increasing integration across tools and services. "Most people think about integration right out of the gate," he said. "You can integrate a lot of these tools to help you optimize your product easily."

Finally, he said he's excited about the data that you can get out of the tools. Product debates no longer have to be so subjective. In the past it could come down to people's opinions about a feature. "Someone would win and that's what you would launch. Now you can actually get data with A/B testing. That's also raising the bar." He concluded by saying, "if you can get answers, instead of having to speculate, then the products are going to get better."


Thank you, Dan, for generously sharing your knowledge and expertise. You are a Champion!

Interested in hearing more of what Dan has to say? Follow him on Twitter, LinkedIn, or check out Olsen Solutions. You can also see many of his presentations posted on SlideShare. Readers in the San Francisco Bay Area can join Dan's new Lean Product & Lean UX Meetup group, where he will be speaking on March 18th.

Do you have a story to share about the awesome things you do with Balsamiq? Send an email to champions@balsamiq.com with your stories or blog posts!

Get the Inside Scoop

We'll send you just one email a month and share a ton of information that you'll get before everyone else. More info about the newsletter here.

We'll never share your email address or spam you.

Leave a Comment

Your email is never published nor shared.