What I Wish I Knew When I Shifted to Product Design

I was Kalibrr’s product designer for enterprise products from 2015 to 2017. I joined when we had ~10k jobseekers and ~500 jobs on the platform. By the time I left 20 months later, we had ~900k jobseekers, >3k jobs, a different business model, a mobile app, and a budding Indonesian platform. It was a growth spurt. And when you grow that fast, you earn a few battle scars. This article is about my battle scars.

Full disclosure: I had zero product design experience coming into my role at Kalibrr.¹ Most of my teammates came from a design background so I had to catch up. It wasn’t easy. Imagine being the only designer working on the platform’s recruiter-facing side and working on two to three revenue-generating, major features all at the same time.

All that while still trying to learn product design. Brutal.

I did a lot of all-nighters. And days where I dreaded coming to work because my boss would be reviewing my designs and telling me they weren’t good enough. Or that they were sh*t. My boss didn’t sugarcoat stuff too. She laid it down thick.²

I learned things the hard way during my time at Kalibrr. I wish I learned these easier — and earlier — but I didn’t know where to look for advice. I hope that by listing it down here you avoid learning it the hard way like I did and pick up a few things earlier than I did.

On Decision Making

Disagree and commit

At a startup, it won’t be uncommon to have differing opinions. My product manager had a strong vision for the product, which sometimes clashed with how I wanted to design it. I often had to commit even if I disagreed. Committing meant that even if I didn’t agree with the decision, I did my best to execute. Why? Former Intel CEO Andy Grove said it best, “If you disagree with an idea, you should work especially hard to implement it well because that way when it fails you’ll know it was a bad idea. Not bad execution.” The benefit here is that we reached a decision quickly. Speed matters in business. Because...

Decisions aren’t permanent

In life, there are “one-way doors” and “two-way doors”. A one-way door is a decision point that you make where, if you don’t like what’s on the other side, there’s no way of going back. A two-way door is where you can go back to your initial state. I learned that, with startups, there are very few “one-way doors”. Many decisions are reversible and do not need extensive research or planning. Instead of spending a lot of time researching or planning, you should...

Have a bias for action

When I started, I would take days or weeks conducting research. But, this was just probably me delaying making a decision in the guise of “getting more data”. Classic analysis paralysis. In startup life, I learned to accept the occasional mistake. When you move fast, you break a few things. Just fix it. Having a bias for action allowed us to course correct quickly.

On Getting Feedback and Iterating

Talk to your users

Cliché, yes. But it’s only a cliché because it’s true. And there’s a reason why this is often repeated in product circles: product people forget to talk to their users. Talking to your users keeps you grounded on their problems. During the week, I would either try to talk to job seekers over our customer messaging platform or join a client meeting with recruiters. Talking to job seekers I learned about their job hunting struggles and their woes with the job application process. With recruiters, we talked about how Kalibrr could help them find the right candidates and avoiding no-show candidates. Conversing with them helped me build a better understanding of their problems. Which helped me build better features.

Wrong solutions can be fixed, but non-existent ones aren’t adjustable at all

We were always free to conduct our research — and we did. But, we also learned to allocate the appropriate amount of rigorous thinking for the problem. The team was set on shipping features as fast as we could and iterating on them. We had our deadlines. And we shipped. Always. And because we shipped, we learned new things. And we learned more — about our customers, about the product, and about ourselves — and we adjusted. We shipped again and, this time, we shipped better. We enrolled in the Jason Fried School of Shipping.

Smaller steps made often is better than big leaps made once

I think this is extremely valuable and, looking back, I wish we could have taken smaller steps and shipped smaller features. This way we could have received feedback sooner. Instead of spending time and effort working on the wrong feature or going in the wrong direction, we could have shipped the smallest product, received feedback quickly, and course corrected.

Getting feedback is one of the fastest ways to improve yourself

Early on, I wasn’t used to receiving feedback. I used to take it personally. But getting feedback teaches you a lot about humility and separating yourself from your work. You are not your work. (I know. It’s hard. But, it’s true.) I came to this understanding when we did daily feedback sessions. You learn early if you are going in the right direction or not. So, go get feedback, go get criticized. Because, as Donald Rumsfeld said, “If you aren’t getting criticized, you may not be doing much”.

On Product Design

Design for the users, not their bosses

Designing consumer and enterprise products are very different things. This went completely over my head the first time. With enterprise products, those who purchase it are often not the same ones who use it on a daily basis. While users in a consumer market have all the purchasing power, an enterprise product’s users often had little to none. Users’ bosses often decide which software to use, and their budget was a significant factor. This affected how we elicited requirements, design and rolled out software, and gathered feedback. So, while it’s important to get the boss’ approval, be wary of designing features to appeal to the boss.

Every action has a consequence, every consequence has a consequence

Knowing our metrics and our user’s needs influenced how I designed our features. And, it was never easy. Marketplaces are complex systems. And, complex systems have many moving parts. When we made it fast and easy to post jobs, we also unintentionally increased fraudulent “recruiters”. When we made it easy to send job applications, we also unintentionally increased the candidates the recruiter needed to needlessly filter through to find good candidates. Think about — and really consider — the probable and unintended consequences of the what you are optimizing for.

Different businesses focus on different metrics, necessarily

I thought that increasing users’ engagement with the enterprise product will increase their perceived value of the product. Not really. A lot of consumer products, like Facebook and Netflix, depend on high engagement — i.e., more time-on-platform — for users to see the value. But, for both our consumer and enterprise products, we wanted them to get tasks done as fast as possible: find the best jobs or candidates quickly. Especially true for recruiters who won’t have all day to sort through their candidates. They have other tasks too. And other platforms they do it on. Our features should focus on helping recruiters get stuff done, and getting out of their way.

Think about how the design might evolve in the future

This matters because designs are never one-off. We iterate on them for a variety of reasons: to improve user-friendliness, to minimize errors, to avoid an unintended consequence, and more. So, in hindsight, I wish I made some of my design solutions more flexible. How? I could have considered how the whole experience will change in the next iteration. How certain features will evolve as we scaled, how evolving features will affect what I’m designing now, what happens if some of the functionalities in a feature need to change, and how the different sets of personas evolve and how the platform evolves with them.

Sympathizing is not empathizing

Researcher Indi Young advises that before we practice empathy, we should do the legwork to enable us to be empathetic. Designers proudly preach about empathy but, given the amount of effort that requires, do we really practice what we preach? Did doing user interviews sufficiently immerse in our users’ problems? Did conducting that field study once reveal the pain points our users encounter daily? Our ability to empathize is influenced by our socioeconomic status, background, and personal experiences.³ So be careful with the lens you’re using to view problems. Be mindful of how your privilege affects your empathy.

On Learning

You learn a lot of things on your own

As much as I would love to say that I had a welcoming first week at Kalibrr, I didn’t. I just couldn’t keep up with all the smart people. This really kept me up at night. It didn’t help that I didn’t know much about user experience design yet. So, I read books and watched videos and learned by doing and by getting feedback. This went on for months. Trying to keep up with smart people forces you to have a growth mindset. So…

Work with the smartest people you can find

My colleagues at Kalibrr were f*cking brilliant. I often felt like the dumbest person in the room—I probably was, to be honest. They made me work harder and smarter. They also made working fun. They instilled in me a deep sense of humility. These were the smartest people I knew and they didn’t think they were that smart at all. They were also constantly learning and trying new things and talking about grand ideas. Everyone had a growth mindset, everyone. It completely boggles my mind how much I learned in the 20 months I was there. Learned more about life, curiosity, work ethic, and fun from them than they would ever realize.⁴

¹ This proves that Kalibrr was not the kind of place that put too much emphasis on your previous work experience. Still, I was obviously lucky that I got the job without any design credentials or previous experience. Maybe because I was hired by the crazy design lead — who also wasn’t a designer by trade — much to the dismay of my eventual product manager.

² The shit sandwich she doled out didn’t have bread.

³ Social Class, Contextualism, and Empathic Accuracy by Kraus, Cote, & Keltner, 2010

⁴ Joan, Kev, Ria, Rey, Casper, Jaime, Che, Alyssa, Deus, Chris, Faye, Meg, Rance, Gian, Dan, Angeli, Aivin, Norman, Cassie, James, Choi, JE, Tim, Dexter, Paul. Basically, everyone. If you read this, you guys are rockstars. I appreciate you guys so much.