Several emergent themes in software design and development are converging into a new way of working:

Entrepreneurs understand the strategic value of user experience design in the guise of Steve Blank's customer development and Eric Ries' lean startup

Management are entrusting designers with product management responsibilities as frustrated designers are seeking them out

Agile teams are coming to recognize the contribution of UX as designers learn to function in agile environments

Each of these ideas have significant impact on the way user experience designers approach their work and how businesses structure their design and development efforts. Together, Lean UX, Product Stewardship, and Integrated Teams define a cross-functional, balanced approach to delivering software and services.

Lean UX

Traditional User Experience (UX) design techniques were developed in waterfall environments. Designers conduct research, develop models, derive frameworks, and specify detail with the understanding that they have to get it "right," because once the product enters development, changes are difficult and costly.

Lean UX leverages the highly fluid nature of modern lean and agile development practices. It focuses design and development effort on high value users, features, activities, and experiences, and in so doing, reduces the wasted effort and cost of spending time on issues that don't really matter (or don't matter right now). Teams work to shorten the time between forming design hypotheses, testing them, and learning from the results, accelerating delivery while improving quality. Designing and building from the core out helps tune your product vision in response to stakeholder, market, and user feedback.

Lean UX is not interaction design shoehorned into agile frameworks. Product vision, user research and modeling, and truly evolutionary iteration are central to this approach. It stresses lightweight, collaborative, right-fidelity UX techniques to generate, test, and evolve the design of your product.

Product Stewardship

The responsibilities of an agile product owner are vast, difficult, and conflicted. Typically a role derived from product management, product owners are tasked with fulfilling business objectives; they're expected to identify and represent user needs; they must define and drive the product vision; they need to understand and prioritize development efforts and represent the team to business stakeholders. This is not a job one person can do effectively.

Product stewardship relieves pressure on the product owner bottleneck. A UX strategist assumes the role of Product Steward, pairing with a Product Manager to share the mantle of product ownership. The product manager has a bias towards representing the business, the product steward towards satisfying the user, with a recognition that an interplay of these forces drives prioritization of the team's activities.

Integrated Teams

UX has had difficulty finding its footing in agile development. Design work doesn't always fit the cadence of weekly sprints; designers can feel their job becomes a perpetual state of reactive, tactical design; iterations designers thought meant cycles of improvement turn out to mean a progression of micro-deadlines where "done" means "good enough to move on."

Integrated teams extend full membership to interaction designers, visual designers, content strategists, and anyone else who contributes to shaping the product. Most importantly, these cross-functional teams work in pairs: often as like-disciplined partners, but also as designer/developer pairs. This format reduces communication issues and documentation overhead, develops cross-functional empathy, and gives the whole team increased understanding of product vision.

What you can do

I'm terribly excited to be part of this movement to bringing balance to software development teams. You can get involved as well and, in fact, we need you to drive this change in your organizations. I've posted a deck to slideshare.net of a talk I gave at a side event of IxDA11 in Boulder, CO on Feb 8. Feel free to use it to help start conversations at your office and in your communities about how to improve your ways of working. Join a local meetup to talk with others about the integration of design into lean and agile development. Read blogs and follow the emerging voices in the community of lean user experience and balanced teams. Most of all, trust In the power of user-centered design to inspire, delight, and guide your teams forward.

7 Comments

Dennis ZanettiFeb 16, 2011

We are using this concept at my company. We called the role 'Product Architect'. We make our Product Manager responsible for defining Market Requirements (market definition + what problems is the market facing), and then the Product Architect and Product Manager work together to define the Product Requirements (what requirements a solution must meet to solve the market requirements). Then the Product Architect works with the team, filling the Scrum Product Owner role. PMs are still ultimately responsible for scope & directional decisions, while the Product Architect is responsible for the design details (working closely with the team).

Mary LojkineFeb 17, 2011

Interesting post, but I would be nervous about giving product ownership to a committee. To me, the essence of product management is resolving the conflicts between business objectives and user needs by finding solutions that satisfy both. If you don't understand your business and your users, you can't make good decisions about your product. You can take advice from a business analyst and a UX strategist, but ultimately someone has to be responsible for integrating those views.
I'd prefer Dennis Zanetti's setup, where the Product Manager is responsible for scope and direction and the Product Architect deals with the detail, to a split between business and users.

Tim McCoyFeb 17, 2011

Yes Mary, agreed. Dennis, your setup sounds simpatico to ours--it's not a committee, it's shared product responsibility. I'm biased to thinking of this relationship as a pair because that's how we do our design work at Cooper. There are 2-4 people shaping the design but it's not a committee, it's a collaboration. It requires divesting ego from appropriate direction, trusting the particular biases each person brings to the mix, and balancing forces to match business objectives with user goals.

Tristan KromerFeb 18, 2011

It's great to see this sort of thought process going on in the UX world. Now there's only one thing we need...more designers! Seems like there is a dearth of great designers available for startups these days.

@ritchieleeFeb 22, 2011

@Tim. Seems like there's a perception issue here. Collaboration vs. Committee. Same difference really - it's the shared responsibility and that lack of ego you mentioned that's key. When it works, it works well - the end user is a genuine focus. All too often that collaboration suffers distraction with internal teams; whether it be deadline, asylum syndrome or ego creeping in. I argued with you at Pivotal that the ultimate responsibility for quality and the final say should land with the PS because of this. I've come away thinking that your POPS team is the ideal; but that this ideal depends heavily on the character of those individuals.

donato mangialardoJul 3, 2012

I think that the common ground, the guiding light comes from having well modeled Buyer and User Personas. User personas are especially relevant for design. They can adapt to any development methodology. They answers several questions to engineers, are an invaluable tool for product managers and owners and can be tuned and shaped as the team learns (as in lean startup, as an example). No big upfrong work is required, but someone needs to be very good at that in order to start from a baseline that evolves. Then it takes shape. Name, picture, a perfect day, what I hate, what I secretly like, my personal goals etc. I have been promoted 3 times with this approach. Thanks Mr Cooper!!

Nick CosterJul 20, 2012

My company is a product management consulting and training service. In this capacity we are constantly working with clients who are battling to define these different roles in agile environments. Many agile development teams assume that a Product Owner role is ready and waiting for them, without ensuring that they are resourced as part of a development team. This usually results in the role being fulfilled by the product manager who, as Tim rightly states, is already busy interfacing with the business and the overall marketplace to provide the inputs that the development efforts will ultimately need to create a commercial success.
We see the role of "Product Owner" as similar to the Architect role that Dennis mentioned, but it remains a single, non-committe role that is empowered to make product decisions at a detail and implementation level that support the overall Product Managers strategic product and business objectives.
--nick coster (@Brainmates)

Post a comment

Name

Email Address

Comments (Feel free to use basic HTML tags for style)

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.