I’ve become obsessed with SVPG’s blog while on maternity leave. The first couple of weeks after this baby was born, I went down some deep rabbit holes on the internet (is there such a thing as a Prius lowrider? YES). Now I’m much better disciplined in how I spend my screen time. Apparently, learning about product is one of them.

It’s partly because I miss working with PMs. Some of my most rewarding, challenging, and invigorating work has been when I was able to work in a legit three-in-a-box situation. In my current job, PMs don’t really exist. Luckily it hasn’t been a deal-breaker, though it is definitely a form of emotional labor. Teams try to share PM-ey responsibilities. Or the person who hates them the least tries to take them on. Or the team goes without and deals with the consequences.

I have been the person who tries to take on PM stuff, if only because I’ve worked with them before. In fact, I had a couple of moments early on where I thought, “Crap. I’m going to become a product manager at this company, aren’t I? (Noooo).

The downside to “helping out where you can” has been that it leaves less time to “grow as a designer.” Hence, why I refer to it as a form of emotional labor. What’s ultimately most important to me is the product’s success and the team success, not what I get to make, or own identity as designer. Designers have different views on whether that’s within the scope of the job or not.

That’s why this blog has become so addictive! I am learning more about my work, my role, and what I want for my career, than I expected.

For example, in the provocative post, Product vs. Feature Teams, Marty Cagan rationalizes out some situations I have definitely experienced in my design career.

Product teams are cross-functional, their success is measured by outcomes, and they are empowered. Feature teams, on the other hand, are delivery teams that are largely measured by output, tweaking features. (Resist the temptation to argue that teams can be both). The post gets into how one can figure out which team they work in, or manage. It’s real talk, and it made me reflect specficially about the designer on that team and in that business. Apparently I’m not the only one.

Design Transformations

I’ve experienced four re-orgs in the last five years of my career. Two re-orgs in my current job and two in my previous one. I joined my previous job because of its design transformation and inadvertently stepped into a fresh one when I took on my current one. They seem to be par for the in-house designer course these days. What does this have to do with a product blog post?

At face value, these re-orgs look like a company investing in design for it’s own sake, because great design has become table-stakes in the industry. This is not untrue. But I’d argue that a deeper, subconscious driving force behind re-orgs is a desire to transform a business with mostly feature delivery teams into one with empowered product teams. Except like, as soon as possible. Competition is a strong motivator, and the visions that designers sell can be very attractive. We are good at making the complex look simple.

But transformations are a long, messy, non-linear game, and not everyone feels comfortable admitting that. I’d argue that us, the designers, if we bear the pressure of pulling it off, might be the least comfortable. We not only have to transform a business, but we might also have to transform ourselves.

If we aren’t delivering results quickly enough–innovation and shipping that meets the hopes of the business–we might react that it’s the business that isn’t willing to give up its feature delivery culture. Innovation takes time; design takes time.

But what if it’s us too? What if the longer we’ve been in a feature delivery paradigm, one where we are ultimately rewarded for how much we make, and how often we make it, the harder it becomes to switch into the designer (or leader) of an empowered product team?

Which one is it?

The article’s controversial conclusion was that if you’re on a feature or delivery team, it doesn’t matter if you technically work on a product, or if your title is Product Designer. If your company, or team, or colleagues measure success based on speed and output more than anything, you’re not really a product designer. Harsh. There’s a separate blog post about the product design role that explains why.

From my own experience, here are some clues that a design team is in this situation:

1.Job descriptions or postings that have not changed, and subsequently, employee evaluation methods that have not changed.

These two create additional burden on a business in the midst of transformation. Designers making the switch don’t know what an empowered product designer looks like in the eyes of the company. They’re not incentivized to change if they need to continue to work as before. Designers who do know, on the other hand, will be in a position where they can’t do their job.

Certain criteria, if listed as the most important things a designer needs to do, are a dead giveaway that a person is going to be evaluated based on output. Asking for a UX team of one but on a large team. Asking for the ability to code. Asking for mastery of multiple tools and software just in case. The UX/UI position altogether.

Evaluating a designer’s performance as an empowered product designer, using criteria for a feature-delivery designer, is an invalid test, with cascading ramifications to that person’s career growth, job satisfaction, and day-to-day productivity.

2. A drop in, or lack of, feedback from management and leadership.

Let’s say a manager or a DRI knows what an empowered team looks like, but ultimately knows that what they’re really on the hook for is feature delivery. It’s a tricky place to be if your job is to motivate people and set direction. What’s more, what if you yourself, as a manager, are also essentially taking on a new job alongside your reports? Trying to avoid churn because of its terrible effect on output? It’s hard.

3. Poor designer-project-team fit.

Without understanding where on the spectrum a designer stands, it’ll be hard to assign work. A designer who can crank out a ton of high-fidelity stuff in a short amount of time might be a rockstar on a delivery team, but not necessarily on an innovation one.

The skills and outcomes that differentiate a true product designer, on the other hand, are hard to quantify. Putting trust in employees who have them will be new and uncomfortable territory.

4. Design team burnout, growth stagnation, and morale.

It’s hard to be in a position where you’re asked to switch jobs without knowing what the new job is. It’s also hard to do two jobs at once, if you’re trying to work as an empowered team designer while still fulfilling the expectations of a feature delivery designer.

For example, true cross-collaboration, the hallmark of an empowered team, probably isn’t happening on feature-delivery team. It’s limited to management. For a person to try and make it happen in this situation is often doomed.

Maybe I have no idea what I’m talking about

I know all of this can apply to other roles too. Yet designers, perhaps more than any other role in a product team, crave creative freedom. When we think about the feature delivery vs empowered team difference, it’s clear that one situation will afford a designer more opportunity than the other. Once you taste what that’s like, it’s hard to go back to pushing pixels.