Part 3
Lean Product Design in Large Enterprises: Cracking the Code
This is the third installment in a 4 part series that explores the challenges of working Lean in large enterprises. Part 1 addresses common difficulties within large organizations, part 2 covers certain process pitfalls, and here in part 3 we discuss some considerations regarding the role of a Lean designer…
Well Rounded Product Designers are Scarce
Unfamiliar things are seldom found in great abundance — and in most corporate environments Lean product concepts are not super familiar. Finding experienced, talented, well-rounded product designers with the ability to effectively work small and experimentally in large enterprise settings is no easy task.
The scarcity of such people is easy enough to understand. Most software designers still tend to self-identify and organize according to process roles. Individual specialists focus squarely on Research, Interaction Design, Content Strategy, or Visual Design as distinct and particular steps within traditional design workflows. But Lean products are designed differently. Small, dedicated teams must make fast and fluid product decisions — meaning they need to be ready and able to execute any design related activity. Polished and perfected deliverables don’t demark the beginning or end of design functions or resource allocations.
That’s not to say that Lean product designers are unicorns. Whether such things even exist is a topic of wide debate. It’s natural to excel more at certain things or focus on distinct areas of professional interest. But in true Lean and agile environments, necessity dictates that designers be capable enough in every aspect of software design to carry a product forward efficiently and effectively — no matter the task. For that to happen, product designers generally possess an uncommon breadth of experience and talents that span from generative art to methodical science.
Unfortunately, robust design capabilities alone won’t determine good performance in large enterprises. Anyone who’s ever worked within corporate organizations realizes that in order to be effective, soft relational skills and emotional intelligence are of equal importance. Knowing how to coach leaders and other interested parties through a process that at times feels messy and uncertain can be rather complicated. I’ve known many incredibly talented design professionals who are able to craft brilliant agile solutions that failed spectacularly in positions of team leadership due to shortcomings in this specific arena. Becoming an accomplished and impactful product designer requires the ability to both unify and influence — which occurs through deep empathy not only for users, but also colleagues and stakeholders.
In typical enterprise structures, piles of people that fit the above descriptions are not readily lying around. Certainly there are those with the desire and skill to apply Lean as a method, but the ability to do it beneficially still takes time and training.
The keys are moderation and baby steps. Once an organization has the chance to experience the process in manageable doses and grows into an understanding of their own unique challenges, a clear picture of the needed skillsets tends to snap into focus. Initial efforts typically revolve around hiring a core set of seasoned veterans — either directly or by partnering with an agency or consultancy — who in turn are charged with building out a broader team over a planned period of time.
Keeping Pace with the Evolving Role of Designers…
— Hire for Design Diversity —
As we’ve discussed, Lean product designers must possess a solid and broad baseline of skills. But nobody will be a total rock star at all of them. Embrace that reality. Teams are far more likely to produce impactful products by exemplifying a wide range of diverse thinking and expertise. Already have a visual genius? Bring in someone who excels more at research. Have a designer that’s great at driving high-level product strategy? Pair them up with someone who shines when creating interfaces. The ability to mix and match the strengths of design team members who challenge and stretch one another is of monumental importance. Those teams almost always achieve stronger solutions than any like-minded group of designers who all matched an identical set of hiring parameters.
— Acknowledge Problems Early —
There’s a difference between acknowledging the strengths of individuals and having someone unable to perform essential product design functions. When working Lean, some level of basic acumen is required across all core competencies — including user research, interaction design, usability testing, and visual execution. If a designer expresses unwillingness or shows the inability to proficiently lead any of those activities, they’ll rarely succeed.
In part 2 of this series we discussed the significance of taking good first steps when experimenting with Lean methods. But those initial tryouts are rarely positive when forced to rely on designers with half the needed skills. The best way to deal with those unfortunate situations is to avoid them in the first place. Hire carefully and patiently. But no level of caution can ever eliminate the occasional mismatch. On such occasions, real-time feedback and kind honesty will generally result in corrective actions while at the same time treating everyone involved with respect and dignity.
— Don’t Confuse Artifacts with Software —
Don’t be afraid to consistently re-evaluate and simplify what’s needed to design and build working software. Detailed documentation makes sense for methodical waterfall hand-offs, but it can destroy productivity in less rigid agile systems. When designers span the full breadth of project activities it’s surprising how few materials are actually needed to create quality software. The time once spent perfecting deliverables that record design decisions can now be spent moving a product forward to the next task at hand. Manicured artifacts take time, and time is one of our most valuable resources. Always question whether or not a deliverable is actually needed. In some cases, it is! But it’s surprising how often we resort to creating things simply because we were trained to do so, or out of comfort with the familiar.
Lean product designers don’t work as practice specialists in silos, and their project outputs should mirror that fact. If they don’t, perhaps it’s time for a closer look.
Performance Evaluations Must Evolve
At its core, Lean software design exists to quickly launch user-centered product concepts to market and continuously chart the best course. In some cases — especially when first exploring new opportunities — solutions simply need to fail. In part 2 of this series we covered the importance of accepting quick failures from a process point of view — but this will never happen when members of an organization know they’ll be punished for it. Failure is obviously never the actual goal, but when enterprises are working the right way at the right speed it’s a natural and expected occurrence — some might even argue it as proof of operating in unfamiliar territory. But the idea is to have it happen as rapidly and painlessly as possible, because things learned or discovered through those failures are typically the seeds of wisdom that precede significant innovations or breakthroughs.
But in most large organizations, anything resembling “failure” is the career kiss of death. The average corporate employee spends significant time every single year documenting accomplishments, fully aware that the students with the most gold stars will move to the front of the class. This creates a problem. When professional advancement requires an annual list of carefully curated success stories, the result is a crippling conflict of interest. Balance gets lost. The ability for team members and stakeholders to critically and objectively assess product performance becomes difficult with yearly evaluations just around the corner. Healthy and needed events like major course corrections or complete concept reboots are seen as the result of negative missteps — and are avoided at all costs. In Waterfall environments…point taken. But in Lean environments it’s paramount to redefine what constitutes true success.
This does not excuse Lean practitioners from doing a good job — accountability is not negotiable. But what defines “good”? How are desired business outcomes being measured? What unique insights were gained through a perceived failure? How did a practitioner enable and influence others towards growth and success? Asking the right questions and knowing how to find accurate answers is the only way to genuinely gauge product efforts.
How to Assess Lean Performance…
— Track Holistic Product Histories —
Rarely do wonderful products spontaneously erupt into existence. They’re often built from insights and ideas born during previous product or service design efforts. Never lose sight of that holistic view. Make sure that all contributors to a successful product receive due credit — including those who may have indirectly provided key knowledge derived through past experiments. When that type of recognition becomes engrained in a culture, practitioners can critically assess the results of their work free from bias and subconscious fear.
A few simple things make this possible. As projects kick-off, carefully record and share all relevant precursors. When projects wind down, conduct postmortem meetings to synthesize both good and bad lessons learned, and note the people that produced those results. Once a product matures and is providing real business and user value, properly reward everyone that made it happen.
— Measure More than Outputs —
When evaluating individual performance, focus on rewarding identifiable contributions to a healthy process and environment — not just the product examples that wound up in a trophy case. Even when an effort fails, did a new or unfamiliar activity increase team skillsets? Is a designer mentoring their peers towards greater expertise in certain areas? Admittedly, this gets into some fuzzy soft skills. But appraising and recognizing that kind of positive practice influence is yet another simple way to measure success, and takes misguided pressure off experimental product results.
— Team Enablement is the Key —
Effective Lean leadership stays focused on enabling project teams to work independently towards strategic outcomes as opposed to dictating outputs (more about outcomes v. outputs in part 1). When operational mechanics allow product teams to achieve desired business goals through efficient, direct, and self-driven means — everyone wins.
Stakeholder concerns should revolve around performance indicators that accurately measure progress towards clear business and market objectives, not dubitable lists of products and features. That focus can be difficult to accomplish, because product ideas are fun. Imagining cool things is easy, but building right things takes discipline. Learning how to keep those things straight is well worth the learning.
Part 1 • Part 2 • Part 3 • Continue to part 4…
