If I could tell you three things…about moving into the product world

Hi, I’m Amy. I’m a product designer at Domain.

I work on member experience, our transactions verticals, and our vendor experience. I’m on a team of 11 designers — and we’re growing!

Whether you’re thinking of moving into product yourself or just wondering how things are different from agency or consultancy life, here are some things I’ve learned moving into the product world.

Letting go of deadlines

It might sound silly, but when you’ve gotten used to intense project timeframes, it can feel weird at first to realise there’s no one demanding deliverables for a seriously under-scoped project, or taking the meaning of “deadline” as close to literal as you can get without actually shooting someone. Sounds great though, right? It is, but if you’re used to having these external motivators driving you, then it does take some adjusting.

Another designer that I met recently described the product mentality like this:

“We have these 6 week plans, where we try to deliver something. But it’s like taking the bus — it’s ok if you miss this bus, there’s another bus coming in 6 weeks.”

Coming from the consulting land, it can feel like you’re always running for the last bus. It may seem crazy to miss that sense of urgency, but pulling off a big project under aggressive timelines has an undeniable emotional payoff.

But this phenomenon isn’t really about missing deadlines. In my case, what I missed at the start was the sense of certainty that comes with a defined project scope and timeline. Letting go of deadlines also means letting go of being delivery-driven for its own sake — instead you will need to consider if you’re: (a) designing the right thing, and (b) designing the thing right.

There’s always a backstory

When I worked on client projects, the design team would often come in and have (almost) free reign to overhaul whatever was there before — because let’s face it, it was probably some crappy legacy system, which needed to be scrapped. That’s generally when companies bring in the consultants.

With a product though, whatever you’re working on, there’s a good chance there’s a history there of design and tech decisions that have been made for a variety of reasons. Sometimes a feature has been implemented as a quick solution but you realise now that it doesn’t scale. Or a decision was made by someone previously without any documentation, making it difficult to know what was behind that choice.

Instead of trashing what’s there, I’ve learned that it helps to be open to understanding the backstory. This not only helps you build on what’s already there, the hidden benefit of adopting this attitude is that it can help you understand what dynamics are at play in the organisation, how decisions get made, and what takes priority.

Build it together

Someone once said to me that going into product means you have skin in the game now. That additional sense of ownership makes it doubly difficult to ignore poor design decisions that get made.

I doubt anyone who works in consulting began by thinking, “We’ll just get the new design finished so we can throw it over the wall to the delivery team.” But rarely is it possible to refine an early iteration of a design if you have tight deadlines and an engagement manager breathing down your neck. Though the idea of going back and fixing something is tempting, you just don’t have the luxury, because the project wraps up and you’re shipped off to another office, with different stakeholders, working with a different industry, and a new team.

When we’re all working on the same product, the relationships with your team are a huge part of what makes the product successful. On any given feature, I might work with an engineer, or a copywriter, or product manager to ensure that what we design and build adds value, not just for our users, but for the business.

Working together also makes it much easier to have empathy for your team. You intrinsically want to build something that “works” because you know it’s your team of developers who have to code it, maintain it and live with it.

After a year, it’s unlikely I’ll go back to consulting or agency land any time soon. There’s still plenty to learn in the product world!

That’s it for today. Do you have any lessons you’ve learned moving into product? Tell me below!