The Messy World of Modern Software Product Development (With User Interfaces)

In forward thinking product development organizations, product management and UX have become increasingly overlapped. Concurrently, we have seen a move towards collaborative design — involving engineers and other stakeholders in the design process. These two factors have had a dramatic impact on how product development teams organize, work, and deliver value to customers. In this post I am going to explore some of these impacts.

A Vignette From the Trenches

Everyone is reasonably good at everything (except maybe Engineering, though some UX and Product folks have chops), and really good at some things…

First, let me paint a picture based on my career and recent personal experience. Imagine a team with a UX researcher, UX designer, product owner, engineers, quality assurance, customer success rep, and an agile coach.

They’re all in a van visiting a customer’s office. They’ve been spending the last couple days engaged in various activities: design studios, customer journey mapping, user story mapping, listening to customer interviews, and building a backlog of experiments to run.

The walls back at their office are plastered with artifacts…stickies from a pre-mortem, a story map, wireframes (drawn by everyone), and a lean canvas. Everyone is engaged and contributing.

The PO isn’t the single owner of the backlog (the whole team owns it). The UX designer isn’t the single owner of the design (the whole team owns it, and is reasonably design savvy as a whole). The PO isn’t the sole owner of defining the problem (the whole team explored it, with help from the UX researcher who did a deep dive a week prior).

And the pairing! QA is pairing with UX to explore interesting edge-cases. An engineer paired with the customer success rep to analyze existing customer data. And the UX researcher paired with the product owner and another engineer prior to the effort to do some preliminary research.

That Sounds Batshit Crazy

This only happens in the movies… As a designer this would drive me crazy …Can’t they just write a spec?

• Sound terribly inefficient? Perhaps, though we are chasing efficacy and outcomes and the madness addresses these goals remarkably well
• Sound impossible without a ton of resources? Probably, if you only just hired your first UX designer
• Sound completely foreign, and you have a tough time believing things actually function this way? It’s rare, but this is how some of the best cross-functional product development teams operate now (2016)

PUX

The product owner gets their world rocked…

The role that has been most impacted by these shifts is the product owner role. No exaggeration, but my role recently as a UX researcher (at a West Coast, recently IPOed SaaS company) was nearly indistinguishable from what I used to do as a PM/PO a decade ago:

• User stories? Yup, as an output of facilitated activities with the team.
• Deep customer/user research? Yup, prior to and during the initiative.
• Measuring the impact of the initiative? Yup, both qualitatively and quantitatively. Lines are blurred. A Director of Product Management remarks:

My biggest problem is the overlaps. Our UX folks and product owners have such an overlap of responsibilities and skills, that it is difficult to keep everyone engaged. I almost feel like a new role or title is in order. Sure, the PO does some of the tactical record-keeping stuff. They do the status checks and keep me informed. But the reality is that this team could run well without one (a PO). My challenge is that we have already established these structures. I can’t just say “don’t work”. I have people to engage. I want them to share in the excitement. But in some cases their getting overwhelmed by all of these very experienced peopleThis isn’t an environment that an associate product manager will navigate with grace. It’s hard. It has become a game of who can contribute valuable context and skills to the soup. A pure meritocracy. The customer needs no representation because the customer is literally on the phone and the team is decently skilled at asking the right questions. Heavy prioritization is unnecessary because the team is moving quickly enough to try new things (with real customers) at will.

One major factor here is the rise of UX. The UX tool chest has always been broad (research, validation, iteration, etc.). They just didn’t get a chance to flex their muscles until recently. Turns out designers make great sensemakers and untanglers and know a thing or two about customer value. Throw in collaborative design, and suddenly your engineers are a bunch of entry level UXers and product owners. Cool huh?

Which in turn impacts the product owner. The formulaic “1 PO per one or two teams” starts to feel very archaic. In its place we ask “what do we need, and who can provide what we need?”:

• If in-depth data science is required, we should find a data scientist
• If coordination with the marketing team is required, we should find a coordinator
• If more context is needed about the business objective, we should find a business analyst You get the idea. To be valuable, product owners must leverage differentiated skills. My prediction: the product owner/product manager titles will morph as new, more specialized roles march to the trenches. I have a simple table describing how I see the product manager role evolving.

The Clan

Where do I belong? Who cuts my check?

In a lightly matrixed environment, it is clear who your clan is. You have a boss. You go back to home base to recharge. Your services are “loaned out” (or even billed out, in some cases) to these teams. It’s a services model. Engineers form the nucleus, and you swoop in when you can to help out.

Things are different with these highly formed, normed, stormed, and performing teams. You now have a team (a *squad?)*. You’ve gone through rough times and happy times. They’ve called you out in a retrospective for slacking. You made up, and formed a stronger bond after the rift.

The matrix is hard. It is made much harder when you are fully embedded on a team. It’s almost not a matrix anymore, except for the pesky question of who gives you your marching orders to a new project, a raise, promotes you, and coaches you. Is it the people who have contact with you day to day? Or the whole network of coordinators and managers who exist to keep the whole matrix pumping?

The services model brand of matrixing has given way to being fully embedded. Everyone is invited to the retrospective. Which ironically has made things much more confusing. My prediction is that we’ll see the matrix dissolve with Spotify-like chapters providing the functional camaraderie, hiring, and career development. Product and UX teams must adopt new structures to evolve.

Patterns and Consistency

It won’t happen without a pattern library…

Jeff Gothelf makes a great case for pattern libraries in his LeanUX book. Reflecting on the last couple years I can say, without a doubt, that pattern libraries are one of the core components in this new reality. To achieve any level of consistency in the midst of all this independence and autonomy, you’ll need more than weekly design reviews. Things are moving too fast for consistency to take work. Consistency needs to be automatic. A solid live pattern library also empowers rapid prototyping and collaborative design. If using the right pattern takes any extra work, then the wrong pattern will hit production.

Simply put, getting the plumbing straight for this needs to happen. It needs to be made a priority. But pulling it together will pay massive dividends.

T-Shaped On Purpose (Or By Accident)

A little of this, a little o’that, and a lot of that…

Whether we like it or not, in this model we’re all becoming more T-Shaped. Wikipedia has some good “Also Known As” terms for T-Shaped:

• Versatilist

• Generalizing Specialist

• Technical Craftsperson

• Renaissance Developer

• Master Generalist The net effect? Well, everyone has something to say about UX and product decisions. It might not be perfectly informed, but it’s not like you’re operating in a vacuum. Low and behold:

• The engineer has a better UX solution

• The team refuses to release the crappy MVP

• The product owner can wireframe like a bat-out-of-hell

• We all have trained for years to do things that aren’t as easy as they seem (but the team will think they’re trivial) This requires a big dose of humility, perspective, and empathy. Great story. After finishing and summarizing a customer call (audio edit and notes), I asked an engineer for some technical help. He solved it with a brilliant one-liner.

Me: Dude, that was amazing! I could never do that in a million years.
Eng: No, no … I could teach you. That call was amazing. Great stuff. I’d never be able to do that in a million years.
Me: No, no … I could teach you.Get used to not being the smartest person in the room. And get used to having to show people your value, instead of hiding behind process or titles. In prior realities someone would toss an idea over the wall, and another team would pick it up. They’d grumble and curse about your mistakes and incompetence, but it would never get real. Now things get real, and that’s OK because you’ve made your environment safe right?

If not, you’re in trouble. Scuttlebutt makes this all fall apart.

Speaking Engineer, UX, Product, QA

We’re all on **A** spectrum…

What used to get resolved with silos, departments, process, and gatekeepers, is now solved by people working it out together. Newsflash: engineers, UX, QA, and [insert functional area here] don’t always communicate the same way. For teams to function like this you need help (Agile Coaching?), time, and patience. You can’t just drop a junior person into the mix and hope they “pick it up”. To an outsider it’ll seem crazy.

We all have to develop great communication skills. There is no filter, and waiting around for one would be kind of silly.

In Closing

This has been rambling, and I’ll probably go deeper in future posts. Let me try to recap:

• A lot of rules, process, and titles get messed up the further you advance down the road towards fully autonomous, cross-functional teams. If you try to cling to the old way, you’ll really confuse people. You have to take the plunge to discover new structures and ways of working (which will also confuse people)
• The further you evolve the more challenging the PO role becomes
• The Matrix dissolves or morphs. New structures and ways of working rise from the ashes. Anyone can provide value anywhere. You’ll still need to become an expert at melding with new teams though
• Anything that happens “just because” doesn’t cut it. Is the team functioning with the necessary skills and hats? If not, change things
• We need to adapt to a new reality of T-Shaped individuals, and learn how to communicate without pre-defined processes
• It’s messy as hell! And the tendency is to say “oh, it’s too messy and inefficient”. But if you let these types of teams build their mojo you’ll be blown away by the results