Designing for Series A
I am a Product Designer, and for the last year I have had the privilege of working as employee number one for a seed-funded, FinTech startup called Pariti. In this article I am going to talk a little about what it’s like to be a Product Designer at such an early stage, and about the seven key learnings that have shaped Pariti over the last year.
Pariti is an iOS app that helps build financial health. We do this by consolidating all your live balances and transactions, so you can see what you have now, and what you’re going to need in the future. Effectively, we can tell if you’re going to run out of money before it happens.
I found Pariti on AngelList, which is a great place to look if you’re interested in doing the work I do. Pariti kicked off 2015 with a very simple prototype that connected to your bank accounts, tested our technology and managed to secure us a £250k seed round from JamJar investments, and seven Angel investors. When I joined in April 2015 we had some money, some beta testers, a million ideas, and twice as many directions we could take.
Learning 1: Start with your users
Having a prototype out already meant that I had a pool of early adopters that desperately needed a product to help them with their finances. (So much so that they were willing to download the original Pariti prototype despite its complex UX and orange colour palette). This represented my first experience running Product Discovery interviews, and if you’re in the same position I’d recommend watching these and reading this.
In the UK, we don’t generally talk about our finances to our closest friends, let alone strangers, and yet I had people emailing me photos of their spreadsheets, or taking the time out to talk to me about exactly how they had fallen into debt, point by point. These guys shaped our personas, giving us real insight into the problems we wanted to solve. They also revolutionised our ability to make product decisions, because we now knew who we were designing for and what their needs were.
Learning 2: Deadlines can be good for you
Once you already have a product live the next steps are often quite clear; best case scenario they are being begged for by your users, or easily qualified by a business need. However when you first start it can sometimes feels like there are no best practises for that initial jump into product design. We spent far too long trying to define our exact product vision, before we actually had a product to be defining. The thing that saved us from this? A deadline.
It has been said that to win the space race you need big problems, big goals and a deadline. Our deadline came in the form of an amazing, and expensive, iOS contractor whose time we needed to prioritise.
Contractors are great, not only because they are (generally) good at what they do, but actually because they are expensive, so it forces you to get the most out of them. Prior to Ben, our small team of four had been pretty laissez faire about how we shipped work at Pariti. What he taught us is that you are never too small to adopt an effective agile process.
My own process now works like this: we have two weekly development sprints, which I actively contribute to in terms of sprint planning, backlog grooming and daily stand-ups. I try to always be at least a sprint ahead of development, and to make this easier I break my own work up into two week sprints as well. This means that as the developers kick off their new tasks, I will often begin work on a new design or iteration that we want to adopt in the near future. I’ll work closely during this experimental phase with my CEO, who I share the product management responsibilities with. By the beginning of the next week I’ll be testing those designs and prototypes out on our pool of (very generous) beta testers. I usually do this using Sketch, Flinto and Skype; whatever allows me to work quickly. By the end of that sprint I’ll have acted on whatever feedback I’ve got and will either return to the experimental stage or will prep those tasks for development using ScrumDo and Zeplin.
In the prelude to us raising Series A, we have some key performance targets that we are trying to meet, and consequently have a very defined roadmap of Product Wins that we try to focus our development work around each sprint. This means working fast, getting as much input as possible from the developers, and testing quickly. To do this I will also sometimes use services like usertesting.com, which allows me to prep a bunch of tests on a Friday and then get the (video) results back on the Monday, straight to my inbox.
Learning 3: Everyone’s a hustler
When there are only four people in your company you will find that a lot of roles become shared responsibilities. One of these responsibilities includes hustling. As Peter Thiel says in Zero to One; “if you don’t see any sales people, you’re the salesperson”.
If in order to achieve success your company needs to get a specific partnership / to be featured by Apple / or to hire someone special…then you need to go out and find the people that will help make that happen. Attend the meetups they are at, host hackathons that will get you in the same building, or at the very least contact them and ask for what you want. (I know someone who was able to get featured in the Apple Store ‘just by emailing to ask for it’). Do not expect things to come to you. They won’t.
Learning 4: Get support from outside of your company
I describe myself as a product designer. What that currently stands for is part UX designer, part user researcher, part product manager, part branding evangelist and more. It is hard working in a design team of one. I miss the collaboration, support and shared skill set that I had when working with talented colleagues like Niklas Eklund and Vittorio Veneto. To get around this I run regular ‘Speed Testing’ nights. (This is like Speed Dating, but for designers to test their work out on each other).
We meet at a pub in Old Street and are able to combine our shared knowledge to help lift each other from what I refer to as ‘tunnel-syndrome’. (Tunnel syndrome is being so close to your product that you can’t clearly see what you’re doing anymore). This kind of support is mutually beneficial, and therefore is totally easy to find if you’re looking. You just have to identify the other designers / developers / founders that are in the same space as you.
*If you fancy coming along to a Speed Testing night then let me know @whebdesign
Learning 5: Branding vs. product
One of the things I find hard is how to divide my time between ‘exciting and fast-paced’ product development, and ‘slow and steady’ branding development. If you are working in this space then you will need to find the balance between these two responsibilities, be it by time-boxing, or including branding work in your ‘sprints’, etc. Never underestimate the power that a strong and sexy brand might have on your future or current investors.
I see product as being about building things, whereas branding is about building belief. As Andi Plantenberg says, ‘A brand is nothing less than the space your company occupies in someone’s brain’, and this will take time to build. Find shortcuts for sure, but give your branding the thought and time that it deserves.
Learning 6: Remember to celebrate milestones
A really good product discipline is to write up the press release before you invest time into building a new feature. If your press release sucks then you can immediately bin or iterate on the idea, without having lost any significant money or time. At Pariti, we also try to pre-define how we will celebrate a milestone before it happens. This helps you keep your immediate goals in check, and it also means that you remember to celebrate when things go well, rather than rushing on to your next task.
Learning 7: Embrace your limits
I am going to end with the thing I most love about working in this space, which is the ability to know your limits. At previous companies that I have worked at, it has sometimes felt like everyone’s job was to just move work around different teams, rather than actually get stuff done. On top of this, there was often an unrealistic expectation that we could do everything, which made it hard to prioritise against what was actually achievable.
In a really small team it is impossible for you to do, or be amazing at, every single thing. Fortunately, this automatically makes it ok for you to ask for help, admit you need to do more learning, or to contract out work that would be better suited to someone with more expertise. It forces you to prioritise the time you have in the best way possible, according to your product needs, business needs and timeframe. It also allows you to say no to things that are not directly related to your core goals.
To summarise…
- Start with your users,
- Don’t be hating on deadlines
- Hustle (!)
- Use your external support networks
- Balance your time between product and branding
- Remember to celebrate your milestones
- Embrace your limitations
There are undoubtedly stresses and downsides to working at such an early stage startup. I think that if you don’t enjoy working under high pressure, taking on multiple roles or designing in a very limited timeframe, then this probably isn’t for you. However as I look around at our (now) six-person, Index-funded team, I see that we are all still as excited as ever about building better financial health for everyone.
If that’s interesting to you, we are currently hiring.
Here’s to the future :)
