When a Product Manager of legacy confronts UX.

I’ve been sitting on this blog post for quite some time trying to articulate how I see the two sets of roles interacting and co-existing with one another. I’ve been in both these roles both separately and collectively and it’s really a puzzling uncomfortable experience.

The problem today, is simple — UX has traction and before we all start high fiving each other on this victory, we still need to reconcile how this whole thing is going to work.

Today, typically UX is a huge challenge for product teams to invest in, especially if they are deeply entrenched in legacy solution(s) that range in age (5–10 years old). The challenge isn’t about providing “reasons” to go full UX, as anyone who’s picked up a tablet/smartphone will get the reasons immediately.

The real challenge lies in the “how” do we move away from this old way of doing things to the new way of doing things that are often filled with “excuses” or “nostalgia” fuelled ranting. Moving forward with the times is hard enough but even more so when the reaction to UX is to just “hire” some UX person to dig everyone out of the hole they are in without a strategy being in place to begin with.

As a UX Architect it’s somewhat more of a challenge for me than it was being a Product Manager, as in this role my job is to provoke teams into taking an introspective look at how they have arrived at where they are at today — chances are the very people in the team haven’t always been there through the whole journey either.

If you ask a team three simple questions “What features do you have right now?”, “What’s working and what’s not working” and lastly “what do you want to do tomorrow?” well you get some pretty awkward frustrated looks (greenfield projects obviously it’s not the case). As really what I’m asking is “do you even know what you’re doing right now?” and it’s a pretty intimidating question as it forces people in that space to admit “well…not really..”

As a Product Manager you’re really there to help steer the ship in a direction that has usually momentum attached and having some upstart UX guy make you sit down and account for what you have usually isn’t an appealing process given well “that’s the past lets talk about the future!” is the vibe at the time.

We don’t ask these questions of status quo to weaken the position of the team or detour them from the future, it’s really there to give us all a platform to build up from. If they can answer the questions that means they are ready to start attaching “features” to “personas” so then we now have a better understanding of who owns what feature and why, which then leads into how you can take the said features and distribute them around various flavours of devices/desktops etc.

Product Management and UX go hand in hand and the danger of a UX role is they could very easily become a Product manager, as its very easy to slip into this role especially if the current status quo doesn’t have a strategy on where they are going or how they arrived at the point in time they are in today.

In summary — A UX role has to sit down unpack his tool kit, and simply break down the product back to its grass roots, force the team to sit down and focus on what they have right now and what they want to take from the past into the future while at the same time create “new”. It’s not as attractive at times but it’s the reality that must be faced otherwise you end up like Microsoft did in the past “oooh look shiney object, let’s go make it and screw what we have right now” (aka Silverlight/WPF strategies to date! :) )