Solve problems, don't just talk about them: How to snag a design role at an early-stage startup
Rob Jones
I joined Warp, an early stage startup, as the sole designer in January. We didn’t hire Dave, our newest designer until August. The plan wasn’t to spend 8 months interviewing designers. That’s not a fun way to spend the better part of a year and I was busy enough as it was. We just couldn’t find the right person.
We spoke with a lot of talented people who had impressive backgrounds. They would nail the screening call, behavioral questions, and portfolio presentation. However, during the collaborative portion of the interview (where we solve a problem together), we often felt frustrated and lacked a clear signal that we had found our next team member. It was evident that there was a misalignment in expectations between us and the candidates. After a particularly challenging session, our CEO, Zach, pulled me aside (on Zoom) to get my take.
“What’s the deal? That’s like the 10th designer that spent 45 minutes talking about customer problems instead of how they would solve them. It’s like they’re afraid to try anything!”
As a designer who has conducted hundreds of interviews over the last 15 years, the problem was obvious to me.
Having experience at large tech companies as well as early-stage startups, I have learned that there is a significant difference in what they value and how they approach problem-solving. Unfortunately, many designers struggle to identify and adapt to these differences. They may have the necessary skills for the job but fail to adequately demonstrate them because they are applying the wrong methods to the wrong company.
Big companies move slow.
During my time at a well-known tech company, I spent nearly 6 months working on a single feature. The glacial pace was maddening. We meticulously mapped out user flows until every edge case’s edge case was accounted for. Some of my diagrams were so big that Lucidcharts chugged under their weight. We designed and then redesigned the interface seven times, each iteration tested over the course of weeks. It felt endless.
By far, the biggest temporal black hole was research. Before diving into the charts and designs (the fun stuff), we dedicated nearly two months to thoroughly understanding the problem at hand. This involved documenting our assumptions, a ritualistic acknowledgment that without evidence, you don’t know enough to be truly helpful. We organized and conducted numerous customer interviews. We generated so many sticky notes that we could have single-handedly boosted 3M's quarterly targets. I became so immersed in our customers' problems that I occasionally forgot where I worked.
The emphasis was on rigorously building knowledge before generating ideas and solutions because solution generation without quantitative analysis is seen as risky. This dogmatic mindset is prevalent in big tech and extends to their hiring process, where employees seek candidates who mirror their work approach and penalize those who do not. I am more guilty than most as I personally created a cheat sheet to help my fellow interviewers keep track of candidate sins. Did they:
- Identify their assumptions?
- Ask about constraints?
- Break down personas?
- Define JTBD (That’s “Jobs to be done” for the uninitiated)?
- Jump to solutions?
I may be exaggerating a bit, but you understand my point.
Early-stage startups are quite different from established companies. They often have limited resources and tight timelines, and cannot afford to be too rigid in their processes. Therefore, they require designers who are flexible, adaptive, and capable of quickly exploring multiple solutions to find the best ones.
During a typical collaboration session at Warp, we prioritize a designer's ability to think on their feet, iterate quickly, and adapt to changing requirements because this is how we actually work day-to-day. If we were to spend two months solely on research, we would not survive and VIM mode wouldn’t be a cool new feature we are about to ship. Unfortunately, this approach proved to be challenging for most of the designers we interviewed, as they were accustomed to a more structured approach. Even when prompted, they struggled to break free from their predefined processes and collaborate effectively with the team. They were almost paralyzed, incapable of actually putting pixel to screen until all research boxes had been checked. As a result, many sessions concluded without any meaningful design work being accomplished. Out of a sixty-minute session, approximately forty-five minutes were spent excessively focusing on the problem space, while hardly any time was dedicated to exploring potential solutions.
Designers need to be adaptable and versatile. They should be aware of the differences between startups and more established companies and adjust their approach accordingly. While having a solid foundation of design and product thinking principles is important, it is even more crucial to know when to apply them.
When applying for a position at a big tech company, it is essential to demonstrate a comprehensive understanding of the design and product thinking process. On the other hand, when applying to a startup, it is crucial to be adaptable, agile, and quick in exploring multiple solutions. Embrace the differences and adjust your approach accordingly. As they say, "Read the room."
So, If you're a designer trying to join a hot early-stage startup and are struggling to make it happen, it might be time to consider a different approach. Shake off the dogmatic burden of structured problem solving and just start solving problems. Experiment, throw out ideas, create mock-ups. Let's save ourselves another 8 months of searching and jump straight to solutions, please.
