The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #265 Josh Seiden - Lean UX for Enterprise

March 11, 2015  ·  14 minutes

Listen Now

Download the MP3

With the widespread adoption of Agile development methods, Lean UX has grown in popularity in the user experience world. It’s built around small, collaborative, cross-functional teams and is an extremely useful approach for startups and smaller teams. However, challenges arise when trying to adapt it to a larger, enterprise organization.

Show Notes

Josh Seiden, co-author of Lean UX and principal at Neo, believes that even though the Lean UX practice is a natural fit for small organizations, it can work well in any size organization. The main thing is being able to identify the things that you may get hung up on and working through them. In his virtual seminar, Lean UX for Enterprise, Josh talks through some of those “gotcha” moments and discusses how to implement Lean UX tactics.

Josh received a bunch of great questions during the live seminar and he joins Adam Churchill for this podcast to answer some of those.

  • Is there a scenario where your MVP doesn’t have to be version one of your product?
  • How do retrospectives and team agreements factor into the process?
  • What can you do if you have limited access to your customers?
  • Can you have contracts with vendors based on outcomes instead of deliverables or collaboration?
  • What are the issues that arise in two-track Agile?

Full Transcript

Adam Churchill: Hello, everyone. Welcome to another episode of the "SpoolCast". Recently, Josh Seiden presented a virtual seminar to a sizable UIE audience, and that's called "Lean UX For Enterprise."
The recording of this seminar, along with over 200 other UX seminars, is now part of what we're calling UIE's All You Can Learn. UX designers in large organization have requirement overload, poor access to customers, and little room for innovation on projects with legacy products.
Large companies are interested in the collaborative aspects of Lean UX and the way it brings designers into the Agile process. Sadly, Lean UX is often understood as something that only works for small teams.
In the seminar, Josh showed our audience that Lean UX does scale and that it actually can be very effective in larger organizations. In today's podcast, Josh is going to join us to talk a bit more about some of the questions.
We had lots of great questions, and we just didn't get to them all. Hey, Josh. Thanks for coming back.
Josh Seiden: Hey, Adam. Thanks for having me. It's great to be here.
Adam: For those that weren't with us last week for your seminar, can you give us an overview of what you covered?
Josh: Sure. We started with a little bit of refresher about Lean UX. For folks listening out there who might not be familiar with it, it's a way of working that I think has gotten quite popular in the UX world because of the ubiquitous spread of Agile software development methods.
Lean UX is an approach to doing user experience design work in the context of Agile that helps teams focus not just on building something well but actually building the right thing. We talked a little bit about that.
Then, we talked about some of the challenges of doing it in the enterprise. The method is based around small, cross-functional, collaborative teams, so it's a really natural fit for start-up teams and for teams working in smaller organizations. It works well in large organizations, but there are some gotchas.
We talked about those gotchas and some tactics to overcome them. Happy to talk a little bit more in this podcast about what those gotchas are and how to get through them.
Adam: Let's get to some of those questions. At one point in the seminar, you talk about running experiments to test those risky assumptions.
You said that an MVP doesn't have to be version one of your product. Some folks were looking for an example of that type of scenario.
Josh: The whole idea of Lean UX is that you're working in a way that tests your assumptions in a continuous way as you're working. The key technique involved in that is this idea of the pairing of declaring your assumptions and then testing them with a minimum viable product.
That phrase, minimum viable product or MVP, is often misunderstood, and it's often understood as a kind of version one release of a product. We like to use the phrase to mean it's an experiment. It's an experiment designed to test what you don't know.
For example, a really typical experiment that you might run is if you don't know if customers are interested in your service, instead of trying to build the service you might just put up a landing page and see if people are signing up. In some ways, Kickstarter is the ultimate MVP. You're putting up a value proposition.
You're making a little video about your product, and you're saying, "Hey, are you interested? If you are, sign up, and if we get enough sign-ups, then we'll commit to building the product."
Adam: Let's talk about the teams. You talked about minimum viable process, and you talked about using retrospectives and team agreements. Can you say more about those things and the role they play in the process?
Josh: One of the things about Lean UX is that it's really inspired by a mindset of continuous learning. We just talked about this idea of continuously learning if your assumptions are correct by testing your product in small increments. That same mindset applies to your process, as well.
When we work with our teams here at Neo, and when we work with our client teams, we encourage them to think about process as a continuously evolving thing. We are constantly trying to learn about and improve our process.
The way we do it is with a classic Agile technique called a retrospective. That's just a team meeting. There are lots of different ways to run retrospectives.
It's a team meeting that encourages open conversation about what's working and what's not working. Typically, when they have a retrospective, they commit to making a change to improve the process if they identify something that's not working.
We encourage teams to hold retrospectives on a regular basis in an ongoing project. Every two weeks, check in, see what's working. We track that with a thing we called team agreements.
There's lots on the Web about retrospectives and team agreements. They're really, really powerful tools.
The nice thing about thinking about your process in this way, in an enterprise context, is that as we start working in a new way, you're going to uncover new barriers in your organization. Instead of throwing up your hands and saying, "This process doesn't work," start with the assumption that the process probably won't work and we're going to have to change it.
Then, as you uncover obstacles, you're able to deal with them with more of a positive attitude that comes from knowing you were going to have these problems.
Adam: Josh, one of the things that we're always talking about is the things you can learn from your customers and all the wonderful things that user research does to allow you to make better products. There were a bunch of folks in our audience that their comments were, "We don't get to talk to customers. We don't get exposure to our customers." What do they do?
Josh: As I said in the seminar, this is a challenge for any user experience process in a large company. It's not unique to Lean UX. Although, one of the things that's interesting about the Lean approach is that it's a small-batch approach.
In other words, it encourages you to do an activity, a small amount of design, a small amount of development, a small amount of research, and then repeat. It's sometimes the case, in large organizations, that it's easier to do a little bit of research in an ongoing way than it is to do a big bang project.
What we try to do when we're building these processes, first of all, we always try to pair talking to customers, in other words qualitative research, with data, with the quantitative information. We try and create a rhythm so that every week or every other week you're just talking to a couple of customers. In an enterprise context, that can often be an easier rhythm.
What I always try and encourage people to do is the typical things that UX people do to talk to customers, which is get friendly with your sales force and go out on sales calls. Get friendly with your customer service people and listen in on phone calls. There's lots and lots of techniques, if you're really forbidden from doing it.
Adam: Josh, in the seminar you talked about how to work with third-party vendors. James asks this question, "Can you have contracts with vendors based on outcomes instead of deliverables or collaboration? Is that a sensible way to approach that?"
Josh: One of the interesting challenges in working with a large organization is that you typically don't have as much control in terms of structuring your vendor relationship as you might like. There may be standard contracts that you have to use with your vendors, or there may be contracts already in place.
Sometimes those contracts can limit your flexibility in terms of how you can collaborate with vendors. We always advocate that your project teams be small, cross-functional, and deeply collaborative. If your contract with vendors is based on a fixed deliverable for a fixed fee, you may not be able to change that relationship, either because you don't want to or they don't want to.
My recommendation in the seminar was to try to, if you can, structure those contracts as time and materials, which gives you much more flexibility to collaborate with your vendors. The obvious next step, all of this Lean UX work that we do is based on the idea of stepping away from committing to building features and, instead, having your team commit to creating an outcome.
For example, instead of saying, "We're going to build a new log in page," your team might commit to increasing the rate by which people log in to your site. It's very difficult to build contracts like that with vendors. As a consulting company, we've thought about doing that on numerous occasions.
Part of the problem is that, unlike a start-up team that controls its own destiny, vendors and clients, unless you can create a clearly delineated area of responsibility in which the vendor can be solely responsible for the outcome, most vendors don't want to sign up for that. The simplest compromise between those two worlds is to get the vendor working on time and materials.
Adam: Josh, in the seminar you talked about something called two-track Agile and alluded to certain problems. Jay wanted to hear a bit more about what those certain problems are. I'll ask you to say a little bit about this, as well. He makes the concept that two-track Agile sounds an awful lot like Waterfall.
Josh: A couple of things about this. The first is that I've seen a lot of large organizations with big engineering groups that create different kinds of two-track Agile. To start with, there isn't just one kind of two-track Agile.
One of the things that I talked about in the seminar was the way PayPal has structured some of their teams. They have Lean UX style teams working in the early part of the process, and those teams are designers, developers, and product people working in small, iterative loops. Their goal is to design and validate a feature.
What they produce is a running prototype, usually running in the same technology that the production product will be running in. They, then, hand off that validated prototype to a second Agile track, a production track, that takes that running prototype as the spec and builds a live product out of it. Agile people don't like this because there's a hand-off.
I don't like it because there's a hand-off, and any time you have a hand-off, you risk losing information. The team that validated the product isn't the team that makes the final production version of it. That hand-off smacks of Waterfall, which a lot of people in the Agile world don't like.
''There's a time and a place for Waterfall. When the requirements are well-known, well-defined, and well-understood, Waterfall can be great. We landed a satellite on a comet last year with a Waterfall process. [laughs]
Waterfall's not inherently bad. It doesn't work well when there's uncertainty. I'm a big advocate of the early parts of the project being based on the Agile and Lean methods.
Adam: Josh, very cool. Thanks for joining us again.
Josh: Adam, it's always great to talk. Thanks so much for having me.
Adam: To our audience, thanks for listening in and for your support of the UIE Virtual Seminar Program. Go check out the recording. Again, you can get at Josh's recording in our "All You Can Learn". Thanks everybody. Goodbye for now.