3 Challenges Implementing Lean UX in the Enterprise

Transitioning teams to be more “lean” in their product development is not easy. This is especially true in larger, more established organizations. Years of historical momentum coupled with siloed bureaucracy and overzealous legal departments have entrenched a serial, lengthy process in many banks, insurance companies and other enterprise level orgs. Add to this the relatively late addition of design and ux services and simply declaring, much less actually proving, product hypotheses becomes an organizational impossibility.

Making a list of all of these challenges can be a lengthy endeavor. To spare you that list and to focus this article on challenges with actual solutions I’ve picked three. Again, this is far from a complete list and I encourage you to add your experiences to the discussion in the comments.

Failure is not an option
For Lean UX and Lean Startup to take hold philosophically, your company culture must allow for some level of failure. Declaring hypotheses carries an implicit admission from the product development team that they don’t know if a problem statement is true and if their proposed solution will work. To find out they will need to experiment. Experiments will fail. Management needs to be comfortable with teams learning by failing. The failures will come regardless of process. By experimenting early, your team mitigates the costs sunk into a particular solution.

If you’re facing this challenge here’s what you can do:

1. Communicate with your manager regularly. Let her know what you’re doing, why you’re doing it, what it will cost, how long it will take and what you expect to learn from your experiment. Explain how you will mitigate legal and brand risks. Invite her to participate in your testing sessions. Most important is to share your learnings as soon as you have them. By keeping your manager informed you reduce their anxiety. By regularly communicating progress you’re letting them know work is getting done.

2. Crunch the numbers. Show your manager the cost of fully executing the current, unproven plan. Then show the cost of validating those hypotheses. The drastically lower cost of early failure always helps build support for Lean UX.

Your company manages to outputs, not outcomes

Many companies build lists of features and then task teams with building those lists. When the features launch, the team is rewarded for completing their work. No reward is given for the feature actually solving a business problem – only for deployment.

Lean thinking pushes us to seek the business outcome we seek to create with our feature sets and then question whether these features will get us there.

To overcome output-focused management in your org realign conversations with your stakeholders around what metric you’re trying to move with the current feature roadmap. Discuss how confident the company is that these features will actually achieve that goal. If confidence is low, ask your stakeholders to challenge your team with moving that metric. Let the team figure out which features move that metric and use the communication tactics mentioned above to keep managers at bay.

IMPORTANT: the metric you task your team with must be an outcome they can move as opposed to global corporate impacts (think reduction in shopping cart abandons as opposed to “revenue”).

Silos

Lean UX thrives on cross-functional collaboration. Silos destroy this. Enterprise level organizations often have entrenched silos that lock disciplines and business units within their own walls. Crossing these boundaries often brings cries of “that’s not my job” or the opposite, “isn’t that their job?” The truth is that it’s everyone’s job to build great products. Many of the skills your teams possess go untapped because they reach beyond their job title and ultimately their silo.

To get past this you’ll need a bit of stealth maneuvering. This is a situation that requires asking for forgiveness as opposed to permission. If you can find a few like-minded colleagues from other disciplines, grab them and put together a small skunkworks effort to tackle an annoying problem the business has. It doesn’t have to be big – just enough to show what a motivated, cross-functional team can get done in a short amount of time.

Showcase your success to your managers. Tell them how you were able to get all of this done so quickly. Prove the power of silo-busting by showing it’s accomplishments.

These are not small problems and the tactics here will only get you started overcoming them. What challenges have you had? How have you tried (successfully or not) to get past them?

Share your feedback in the comments.

[Jeff]

P.S. – to learn how others in this position have implemented Lean UX in the enterprise consider attending Lean Day: UX – 9 amazing speakers will share their insight on this exact topic.

About Jeff Gothelf

Jeff Gothelf is an agile product designer, teacher, writer and team leader. He is one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the O'Reilly book (2013), Lean UX: Applying lean principles to improve user experience (www.leanuxbook.com). He is a highly sought-after international keynote speaker, workshop leader & trainer. Currently Jeff is a Principal at Neo Innovation in NYC (www.neo.com).
This entry was posted in agile, design, enterprise, lean startup, Lean UX, Productivity, ux team and tagged , , , , . Bookmark the permalink.
  • http://twitter.com/UXPhil Phil Bonhard

    Hi,

    these are all valid points, but in an enterprise environment they all are prone to hit a wall because of a simple challenge: lack of physical proximity

    In times when the client sits in city A, the design team operates out of different locations and the development is outsourced to India, lean UX is quite challenging to achieve.

    It’s not impossible, but harder.

    Communication technology like Skype, telepresence etc make it a lot easier to virtually colocate, but it’s not quite the same thing as when your entire team sits in the same room.

    I’ve worked in places where:

    - the client sits in Manchester / Newcastle / Leeds
    - the tech architecture in London
    - the development in India

    … being lean and agile there really wasn’t easy.

    thanks,

    Phil

  • http://www.jeffgothelf.com Jeff Gothelf

    Yes, co-location is key to success. It’s one of the many issues I left out of this article but it is critical to the success of these rapidly executing teams.

    Thanks Phil!

  • Pingback: What I've been reading lately (week 2), by Samuel Ericson

  • http://twitter.com/gmdavisUX Gary Davis

    Saw your talk online on UX immersion, bought your Kindle book right away and I really wanted to make this work. It’s like pushing a boulder uphill for me. Trying these daily meetings with the dev team, engineers seem to have a never ending love of edge cases. We did lots of usability tests as a team and I watched in horror as every problem they solved involved adding more text to the screen. It’s as if I have to actually take over an agile project and wrest control from the project managers. I also need to somehow get only one project assigned to me at a time, when we have a shortage of UX team members. Top all this off with a highly distributed remote workforce and I’m ready to go back to staggered sprints. I’m not giving up yet but I could use some advice here.

  • http://www.jeffgothelf.com Jeff Gothelf

    Hi Gary -

    Sounds like a tough but not unfamiliar situation. I think the best approach in this case is, instead of pushing forward a whole slew of new changes, to try and pilot the smallest version of these ideas that you can. Think of it as the MVP – minimally viable process (sorry :-) .

    Is there an opportunity to cherry pick one feature or idea and pilot the process with a subset of the team? Maybe just a designer, product manager and an engineer. Get it working in this smaller environment and then start scaling out — the team first and then on to bigger projects.

    The project managers will struggle regardless because there is no clear place for them on self-organizing teams. They won’t give up control willingly which will make for the power struggles you describe. It’s best to work with them to figure out how they fit into a post-agile world. I’ve seen some of them become scrum masters (who also eventually become irrelevant in my opinion) and others work on non-agile projects.

    Regarding multiple projects — see if you can support one main project and hold “office hours” where other teams without ux resources can come seek your advice (twice a week, 3-5pm, something like that). That may help them and you.

    See my latest blog post on working with distributed teams. Some good tips there.

    [Jeff]