What life’s really like as a designer at Productboard

What life’s really like as a designer at Productboard

It was in the spring of 2018 when I first interviewed for the position of a product designer at a local startup — you guessed it, Productboard.

I’d decided to interview after 2 years of professional life at an organization that provided me with invaluable experience but didn’t ultimately give me what I was looking for in a designer role. Like the lively spring day when I interviewed for Productboard, I’d come to the role blossoming with grand ideas about how I’d shape products and experiences, how people would praise the design, and how they’d be over the moon excited about having designers on their teams…but.

I was naive and I was met with the reality of business life.

There were major constraints around the designer role, and what impact we could hope to have. And like any young ambitious twenty-something, I wanted to do work that mattered, and take initiative to develop ideas into reality.

Looking back, it was a valuable lesson because I found out how I want to work. And, in a way, the role prepared me for Productboard: I saw how an organization with 10+ teams is run, how decisions are made, how teams operate, how work gets planned, and how designers are embedded in product teams and collaborate.
And now, after 3 years at Productboard, and having gained a lot more perspective, my role has evolved even further. I want to share some of that design wisdom with others, and share how designers at Productboard approach work, what the role entails, and why I’m really happy about where we’re going.

From interaction to product design

Photo by Hugo Rocha on Unsplash

The industry of digital design has been rapidly evolving in recent years and there are a number of different job titles covered by the term designer: UX designer, UI designer, Interaction designer and Product designer. All of the above have one thing in common — they all design how a user interacts with a product. But there are nuances between these roles, even though they share the same goal.

A UX designer usually focuses on creating the product logic, making interactions efficient, understandable, and as simple as possible. Interactions create experiences so an Interaction designer is just a different label for the same role. On the other hand, UI designers are primarily concerned with how a product looks. They build on top of what UX designers offer. They ensure visual consistency and make sure the logic is communicated well.

A Product designer’s role encompasses a broader landscape. They’re generally involved in the creation of a product’s look and feel. They need to understand how certain features have to work and why, how those features complement others, and some organizations even look at product designers as champions of user needs. Product designers often zoom out to oversee a product vision but also zoom in to ship features and execute work in delivery.

I started my career as an Interaction designer. I was drawn to an opportunity, where I could work on a complex product that was available on multiple devices with the experience spanning across multiple touchpoints. In my case specifically, this happened to be a 3D printer with a control panel and software where 3D models had to be prepared for printing. And, all this had to work in tandem with a print management solution. I thought it was so cool and so much more exciting than producing websites one after another.

I was working in a cross-functional product team. I wasn’t too concerned about what was going on around me and definitely didn’t have perspective to assess whether we were working the right way and on the right problems. All I was concerned with was the ability to follow our users and observe them in their natural environment, building and testing prototypes that improve people’s lives and make their jobs easier. I was hoping the product would lift off and start selling itself.

Looking back, I wouldn’t say I was necessarily doing something wrong but I just didn’t have realistic expectations and didn’t understand the environment our product was a part of. My focus was too narrow. As an interaction designer, I wasn’t concerned about who the buying persona was, what they wanted to achieve for their organizations, how big a certain problem was, etc. I was too focused on the experience of the end user, but the product was so much more — and I learnt that over time.

But wait, how do product designers usually work?

Productboard’s design organization recognizes three tracks for individual contributors — product designerbrand designer, and design system designer.

We look for well-rounded product designers who are strong in multiple disciplines, including business acumen, research, collaboration and design (think Figma proficiency, visual taste, knowledge of UI patterns, etc.). We don’t differentiate between UI and UX and we don’t have any user researchers on the team at this point. Naturally, not everyone is perfect in all of these disciplines.

But we learn from each other, and for example, a lack of, say, visual design skills, can be compensated for by a robust design system and by frequently showing work at helpful peer-peer design critiques where folks that are strong in aforementioned visuals give you feedback.

There’s naturally a large overlap with a product manager’s work, but we believe that this allows us to produce great solutions for our customers instead of passing over design artifacts from function to function and hoping nothing gets lost in translation. We realize that this is no easy task and we ask designers for a lot so… we also make sure to support each other and work as a team. And that means both as a product team and a design team — which leads us, designers, to have an interesting dual personality. That said, all the designers at Productboard share a desire to improve. It’s one of the attributes we look for in candidates when hiring. The role requires a structured process and a broad arsenal of tools and techniques, which help tackle complex problems. And of course, there’s using the product that we build daily, ourselves. Starting with the below.

Discovery

Photo by Nathan Jennings on Unsplash

The great thing about working at Productboard is that we use our product internally for building… you guessed it… Productboard itself. Designers use the Insights board as a repository of research notes, support conversations and feedback from a few other sources to learn about customers. Every customer-facing colleague is asked to provide customer feedback so that all product managers and designers can leverage this stream of never-ending insights that go into Productboard. And, more to the point, both product managers and designers continuously categorize and make sense of it all, linking insights to problem areas and feature ideas. What it allows us to do is to build a deep understanding and empathy for our customers and spot problems and topics that arise — through the increased number of insights being linked.

Using Productboard means we don’t have to start from scratch when diving into work on any new initiative. Teams are empowered and propose initiatives based on objectives set by leadership. There’s discussion and consensus made, but we have a good amount of freedom within our domains to choose what we’ll work on.

Designers also do a lot of user research in tandem with the product manager and engineering manager (or engineers). When diving into an initiative, we usually start by reading relevant Productboard insights — feedback that’s been captured and categorized over time in Productboard. If that’s not the case, we tend to have at least a list of customers who mentioned the problems we’re after, so together with the product manager, we are more effective when contacting customers and prospects for user research.

For the research part, we encourage everyone on the design team to pull in engineers or at least socialize research call recordings and learnings in their product teams so everybody starts to think through problems and possible solutions. However, it’s not all research during discovery. The beautiful thing about design is that visual outputs lead to better conversations among the team and stakeholders. We use our visualization superpowers to produce solution explorations that lead to saving massive amounts of money by showing what not to build. We tend to push ourselves to create a range of solutions for a given problem. We explore alternatives, flex our creative muscles and make sure to be intentional about choosing the best one.

However, since choosing the best direction can be tricky, we also rely on design team rituals. There are two design critiques per week: we meet with our design advisor once a week and every Monday we encourage the whole team to pair up and design together. We share our work, collaborate and are open to criticism. This way, we lean on our collective knowledge and consider inputs from multiple people while also learning from each other.

Delivery

Photo by Yu Hosoi on Unsplash

In our world, delivery has several stages. Going from discovery to delivery typically indicates that the team has a finalized solution — but, it’s important to stress that this isn’t really our goal. Success in discovery means that, as a team, we all understand the problem, we have a shared idea about the solution and the approach has been validated.

Designers should never default to working in isolation, creating blueprints of solutions that are then handed over. This creates an unnecessary risk of misunderstanding between team members, as well as potential duplication of work or the creation of a plethora of treatments that leads to inconsistency. Not to mention, it’s important that designers involve others from the product team— especially engineers. Firstly, it’s necessary for a realistic and deeper understanding of the technical constraints, but also to build a collective sense of responsibility when working on conceptual solutions; to share knowledge, experience, and a spirit of camaraderie.

At Productboard, we often refer to this stage as the “solution discovery” stage. We’re sure about the problem, but the actual solution may still be hazy. And that’s ok. This allows potentially better ideas to still triumph, and there’s still some level of uncertainty when in delivery. See, it’s not just about executing on a plan in a rigid way.

It’s a reality that designers don’t necessarily understand all the technical implications involved and that’s how teams end up shipping features that are scoped down to a bare minimum; a fraction of an original idea that was meticulously curated and tested by a designer. It’s then questioned whether that stripped solution even brings the imagined value.

Ideal collaboration in delivery includes engineers further investigating the technical solution and breaking it down to manageable chunks, while we keep working on a prototype, conducting usability tests with product managers and engineers, and thus further decreasing uncertainty around whether we’re building the right solution. In delivery, the extent to which a solution can change does decrease, but when we test solutions, the team needs to be able to make time to adjust them based on findings. Otherwise, testing is a wasted effort. So, note: factor in some time for adjustments that may come out of testing.

And finally, the excellent execution of the visual design is an important part of the job. The challenge though, at least in my experience, has been not to get too slowed down by searching for the elusive “perfect” solution, when still deep in the weeds of finding the solution itself. In fact, I dare say that it’s secondary; though once we do figure out the solution, we tend to spend a fair amount of time on the details and the crafting of beautiful designs. It’s dear to our team and we aim to delight customers by a logically organized, clean UI that delivers on expectations and offers simplification and guidance to the product manager’s busy, integrated job.

Success for product designers

The discipline of product design is complex and has many (many) shades that definitely aren’t grey. (Excuse the pun.) It’s a vibrant, interesting, challenging job and success can look different in different environments. And sometimes, we make so many compromises, that it can feel like the features our team ships just aren’t good enough compared to the ideal state which we initially designed for them. But it’s part of a creative’s job to search for the ideal, the vision, the moonshot — because as we like to say, if you aim for the stars, at least you’ll end up on the moon.

Situations, when scope gets trimmed down to a bare minimum (so that it hardly resembles the initial design), tend to happen when engineering isn’t onboard. Then, the shipping of a blueprint becomes lengthier than initially anticipated. I often see this as a source of frustration and a feeling of failure to deliver. And yes, I know this doesn’t have to be the only problem. But after all, we need to remind ourselves that compromise between design, tech, and business is normal and healthy. As IDEO puts it, there needs to be a balance between desirability, viability, and feasibility.

The balance between the three is a recipe for innovation

When you’ve been working on a product for a few years, you know that teams work with limited time and resources and your design doesn’t always end up being built because of a lack of one or the other. But if the team collaborates, compromises and ships, it’s likely to lead to success. That’s why designers should welcome collaboration and make compromises. Building a product is a team sport and solving customer problems and making them happy is the ultimate success.

Looking ahead…

The first employee at Productboard was a designer. This speaks volumes about the importance of the role here. Design is a key function that enables teams to effectively communicate ideas. We’re brought into conversation not because there is a specification and final designs are needed, but because our perspective is valued and we have the power to visualize other people’s thoughts, which allows us to almost pre-test ideas, and thinking.

Our product designers work on anything from new features to how the product is priced and packaged, to figuring out how to shorten the time to value for different personas across segments. The variety of work is exciting and I know that wherever we go in the future, the designer’s role will be an integral part of the business, to which we will be able to make a valuable contribution.

We’ve come from a small team of designers to a team of almost fifteen talented individuals. While my work has changed, the core of how design works at Productboard remains the same. We’re part of an organization where design doesn’t work as an agency but where we play an integral role in the planning and execution of product development — and that, in short, is what I value the most. Being able to think across functions, challenges, and scenarios to influence the business is the design role that fits me best.

What’s been your experience? Feel free to let me know.

Interested in joining our growing team? Well, we’re hiring across the board! Check out our careers page for the latest vacancies.

You might also like

Productboard expanding San Francisco engineering presence
Life at Productboard

Productboard expanding San Francisco engineering presence

Jiri Necas
Jiri Necas
Refactoring Productboard’s design system to the next level
Life at Productboard

Refactoring Productboard’s design system to the next level

Jonathan Atkins
Jonathan Atkins
The Role of Growth Engineering at Productboard: Significance, key skills, and responsibilities
Life at Productboard

The Role of Growth Engineering at Productboard: Significance, key skills, and responsibilities

Stuart Cavill
Stuart Cavill