Joining an early-stage startup as the first designer can be daunting, overwhelming, and sometimes disorienting. On the flip side, it carries similarly extraordinary benefits as well, from having an incredible scale of impact, through a super diverse spectrum of design tasks you'll be shaping and, of course, a crazy fast pace of iteration - you can literally see people using what you designed in the span of weeks.
The founding team around you will play a critical role in your experience, possibilities, and boundaries - design sensitivity isn't a given, and many product teams go quite far with no designers involved, while some opt to contract freelancers or agencies for some specific needs, and on the other end of the spectrum are some, who allocate significant resources towards crafting a very heavily design influenced experience, from day one (think Linear, Resend, etc. ). I was extremely lucky, as my founders - tho both coming from engineering backgrounds - are very design-sensitive, and gave me full support to push design thinking in all aspects of our product experience from day one. While I wouldn’t consider it prohibitive, joining a team with little to no design sensitivity can be a very educational exercise in stakeholder and organization influencing, but it is definitely not for the faint of heart.
I joined Andras and Peter - the founders of OpenMeter - just over 1,5 years ago as they emerged from YCombinator W23, as the first designer in, and now, 18 months down the road, after raising our first successful round of funding, with a team of 8 I thought I'd share some thoughts on this first very critical stage of the journey in the life of a startup from the perspective of product design.
In this series of product design & dev articles, we'd like to share thoughts and experiences around what worked for us and what didn't - not as a singular source of truth, but more as a conversation starter for the broader community.
In this first article, we’ll stay at a high altitude looking at some of the most prevalent challenges of early-stage life, but we’ll get more practical and into actual development as we move forward with the next installments.
Your team is dysfunctional.
And that's fine, they all are.
Every small team I've had the pleasure to work with had a unique constellation of strengths and weaknesses and having the sensitivity and openness to understand your specific team makeup, userbase, customer and business needs and then having the capacity to adapt your workflow and process to mesh with these dynamics will be critical in your success.
Your team will likely be a far cry from the "optimal squad" structure of product, design, research, front & backend engineers, data experts, etc - for reference at OpenMeter we are currently 7 engineers and one designer and this means that I as the sole founding designer am responsible for a wide spectrum of domains including branding, marketing, product design, research, and testing. Formally prescribed responsibilities and boundaries of specific roles and functions dissolve in this realm and everyone needs to stretch and adapt to meet these, much broader, shared responsibilities. Structurally, startups are usually much more flat, which comes with the thrilling freedom of high levels of autonomy, but of course also lack the hierarchical structures, that shield you from the pressures of actually being responsible for the outcomes of your decisions and actions. Ideally, everyone in the team should feel and act as an owner - you take action ( and responsibility) for achieving the mission and seek to improve all aspects of the product even in ways that are not explicitly part of your job.
"We believe design is a discipline that can be exercised by anyone in the company. It is a way of translating user needs and business requirements into real solutions. This process can start with customer support, operations, or engineering."
Zeno Rocha, Founder & CEO at Resend.
This can be a daunting place to be, but remember, though you might have the singular designer label in your team, everyone else also shares these notions of responsibility for product outcomes - in our case, I have a CEO who creates incredible research and product analysis documents dissecting the competitive landscape and doing deep product thinking, I have a CTO who just loves to finesse elegant and scalable UI solutions and I get a ton of amazing feedback, doing mini product thinking sessions with some of our back-end engineers.
As such, classic processes and decision matrices just don't make sense, and to top it all off, your team, your product, and your processes will constantly change as you evolve and grow and you need to remain flexible, open, and curious to find ways to adapt in this ever-changing landscape.
- Understand your team’s shortcomings and superpowers - just because someone has an engineering title, doesn't mean they can't be a super valuable force multiplier for your design thinking + involving your development team early and often really helps break down classic discovery vs delivery boundaries and helps foster a sense of shared product ownership.
- Tailor your processes to your team - it’s very likely that traditional (enterprise-rooted) processes are over-architected, contain a lot of excess, and aren't the perfect match here. For example, as we don't have a dedicated project/product management function, we work with a DRI model (Directly Responsible Individual). This person creates an initial product document, is responsible for getting feedback and driving alignment on foundations, and then making sure the project stays on track.
- Share early, share often, share succintly - startup life is all about the pace of iteration - how fast can you find the parts where your ideas break, how fast can you validate or invalidate, and how fast you can iterate - sharing early and efficiently is critical in this. To reduce noise / static overhead we work with very few fixed meetings, we just jump on tightly focused mini-sync Zoom calls limited to only the directly involved stakeholders and then share outcomes to dedicated WIP (work in progress) Slack channels. Learning how your team can communicate efficiently is crucial - especially if you work remotely - when we first started Peter was in San Francisco, Andras was based in Budapest and I was traveling around Portugal - learning how to communicate efficiently was critical.
You don't have enough time.
Be brutally tactical with where you invest your time.
This will sound a little dramatic, but in essence, at the core of startup life, you are in a sprint for survival against the clock, until you either validate bets, show results, and raise your next round of funding, or you go out of business. That's it. I'm not saying you should constantly be living in a state of existential dread / impending doom, but this harsh reality should inform all of your decisions. Following the Pareto principle, in many cases 80% of results come for 20% of applied effort - identifying where your efforts can have this type of disproportional impact is key - the next time you find yourself drooling over Spline's latest physics-simulated 3D props you wish you could flex on your marketing site - just come back to this thought for a sec.
Ruthless prioritization will be your best friend as you move from zero to one - everything you design has to deliver user value… and ideally, you should constantly be evaluating where your time can have the biggest return on investment - It is super likely that at this early stage, you have some pretty broken experiences - prioritize all those broken windows before you contemplate adding layers of delight, your users will never make it to enjoy them unless you take care of the critical stuff.
For our onboarding experience, we’ve designed state-aware wizards, helpers, tooltips, and a plethora of useful little bits and pieces of continuous education & support to gently guide you to whatever your heart desires, but we have to be very pragmatic with when and where we allocate resources. What we actually have implemented right now is an off-the-shelf little 3-step widget, an intercom button, and some wireframe-level starter templates. It works. Could it be better? Sure - and it will be, but is it more impactful than the mission-critical functionality the team is working on? Nope.
- Before jumping onto a task, zoom out and reaffirm that you are working on the highest impact thing you can be, and make sure you only apply reasonable resources and solve at the appropriate level of fidelity.
- Define what the minimum viable experience that will help you validate the product thesis is, and stick to it - don't succumb to the dark whispers of dribbble - your UI doesn't reeaally need that raytraced-dynamic-frosted-glass-effect to work.
- It is good to design North-Stars, and define aspiration and direction - just be prepared emotionally that it’s going to be scoped down to tiny chunks and MVPs and the parts you love the most will likely not make it into production for a while.
Your product is changing constantly
and that's a great thing.
At this stage of the product lifecycle, your north-star metric should be some variation of learnings-per-hour, so, if you're doing things right, your product will constantly be evolving, changing, stretching, and quite often, breaking. As a designer, this can be quite an uncomfortable position to be in - we naturally have the urge to try and design our ways out of uncertainty, and design systems to cover all edge cases, but when you ruthlessly prioritize the pace of iteration, it’s inevitable that you will need to take shortcuts and things will break. This is fine, as long you can digest the breakdown, learn from it, and adapt to avoid it in the next round of iterations.
You will not have the resources to fully design every system to cover every possible future variation and scaling issue, so you will have to cover some of these as you go and others you will just have to write off to your pile of shame - gasp - design debt. Accruing design debt is quite natural in these early chapters, I think it’s close to unavoidable, so I find it useful to approach it in a way where you simply make conscious decisions around it and have a clear understanding that you will come back to it and you will pay what is due. Typically design debt is not something you iterate your way out of but something that can be approached with somewhat larger resets - check out Karri Saarinnen’s great articles on that.
A cautionary tale; when we first kicked off, what is now OpenMeter, we were called Tailfin - we had a similar core concept, but with a different high-level product go-to-market strategy. I was super excited and dove head-first into a full-on branding exercise spending dozens of hours perfecting a super specific logo, creating branding artifacts, and a flashy marketing site - only for us to pivot and rebrand 6 months down the road. Looking back now, this was a pretty spectacular waste of time and for that initial period while we were just validating our thesis we would have been perfectly fine using any of the first quick drafts that I had drawn up in the first hour or two of that process.
- Embrace ambiguity - we are constantly balancing reasonably risked bets as a startup so you have to embrace the uncertainty that comes with it - it's a natural and unavoidable part of the landscape.
- Accept that things will break - at this stage, it is not a reasonable investment to design all of your systems to handle every scaled-up permutation and edge case. This way of working is rooted in enterprise or agency-scale teams and unfortunately, this just doesn’t work at this tiny scale.
- Only polish things that you have validated - and only once they reach a level of appropriate maturity. Identifying when a feature, flow, or experience reaches the state to be refined to a more thoroughly interrogated and scaled system and should receive a lovingly polished surface treatment can feel treacherously elusive and challenging to pinpoint. This is a constellation of circumstances that will be unique to your product/team context, so I wouldn’t aim to prescribe specific timing, but I do believe these are important principles to keep in mind, before diving in.
Just steal it.
Don't invent things, unless you seriously need to.
I know the rush of dopamine as you crack an innovative model for a problem you’ve been struggling to get a handle on for a long time, but the reality is, that it's very rare that the time investment at this early stage is truly justified. The biggest value you bring as a designer to your team is deeply understanding your user base, developing empathy for their pains and needs, and drafting the smallest possible versions of experiential flows that offer answers for these. Once you have identified and validated these journeys, leveraging established patterns to construct the stepping stones on these journeys is one of the biggest efficiency hacks and an amazing resource you should never be afraid of.
There are amazing, vast design teams out there that have already gone through and ran a hundred experiments to validate that sharing dialog, registration flow, or settings menu, just adopt it. There's no shame in it and you de-risk and speed up a vast portion of your product experience and also free you up to focus on the problems that really need to be solved for your users.
When researching patterns, don't limit yourself to your specific domain - try and break down the issue you’re looking at to its core building blocks, the jobs to be done, the friction to be alleviated and go from there. Just to give you a few examples, our focus mode was inspired by Craft (a document creation app), our onboarding experience takes cues from Wise (fintech) and our filtering is moving in the direction of Linear (a project management tool). If the foundational whys and underlying user needs align, then it’s a match.
- Define clear distinctions between flows that already have established patterns and don’t need deep thinking on your side and which patterns or problems really need your attention, where your novel approach will bring value to your users.
- Look for analogous experiences - even if you are working on a novel product without direct competitors - there are almost always useful analogs you can find if you do your research.
- No shame in this game - Adopting an existing, established pattern makes you a better, more efficient designer, don't let those internal voices of inadequacy tell you otherwise - I’m sure you could design that registration flow from scratch, but you don't have to - save your cognitive cycles for where it counts.
Good enough is good enough.
You can polish it later.
When you start your day using beautifully polished apps like Craft, Linear, or Framer it might be disheartening to use just another ole’ tailwind component, but more likely than not, it’s the right choice, trust me - every minute you spend designing that registration form from scratch is time you’re not investing into solving your product’s actually unique challenges. It’s just not worth it at this point in your product’s journey.
This doesn't of course mean that you shouldn't invest in bespoke solutions, it just means you need to be pragmatic in when and where you do so. Your product will have critical flows, initial wow moments, and many experientially critical points - this is where you need to invest, all the rest can and should be fine with a template solution while you are still validating value.
Another way of looking at this would be to look for scalable systems - where investing in one component or solution can be scaled across your product and therefore bring proportionally higher return on investment.
In our case, at OpenMeter we have a lot of very information-dense forms and tables representing some deeply technical, abstract concepts, which are very important for our primary jobs to be done. We quickly identified that this was an area where we had to invest - we couldn’t simply use off-the-shelf ui components and surface treatments. We’ve worked extensively on the surface level, experimenting with condensed fonts, custom truncation patterns, identifying exotic edge cases, establishing gracefully degrading patterns, and of course extensively testing how our Ui will render on small screens. Of course the above is just the surface, we also pair this with some novel structural solutions to break up the information in a way where it is disclosed progressively, matching user intent with granularity and overall presenting a less overwhelming learning curve and first-time user experience.
- Identify key experiences, where your investment will actually be critical to your users’ experience.
- Look for scalability, where your investment can have a disproportionate impact relative to your investment
- Think in iterative cycles, what you build now will change, and you will have the chance to come back, adapt, improve, and reset. Don't aim for perfection - that's painful, and it's not necessary.
If you’re starting out on your startup design journey or are struggling with some of these themes I hope you find some of these thoughts helpful. In the next blog, we’ll zoom in a little and we’ll take a more practical look at how we built the first version of OpenMeter, what broke, what we reset, and where we still have debt.