Growth marketer turned founder, Sofia built NomNom, a tool that helps product teams manage their customer feedback and share insights across the business.
I met Sofia back when I was a Product Manager at Deliveroo. She interviewed me to better understand how my team was gathering feedback as she was building the first version of NomNom. Sofia always struck me as a passionate product founder – someone who doesn’t stop until they’ve dissected your problem. I jumped at the opportunity to steal an hour of her time for a conversation about her journey as a product-minded founder. We also discussed what it was like building a product for product people (meta, I know!), leading a remote startup and making things work.
I came to England in 2006 escaping the dictatorship in Venezuela. The country was falling apart. There was lots of insecurity and I didn’t see myself build my life and career there. I didn’t speak English at the time, just the basics from school, so I thought I would go to the UK for a year or two, learn and go back. It’s been 12 years!
I’ve been extremely lucky in that I have had the opportunity to do wide variety jobs before starting NomNom. I have worked in change management for large companies, in digital strategy for agencies of all sizes, I have started small size projects that later became businesses and I have joined other people in their ventures. I even had a skateboard shop and a magazine at some point. The last 7 years I’ve been purely focus on SaaS and I’ve been fascinated by the many parallels and connections between SaaS business and more traditional ones. We all like to think that SaaS businesses are a special snowflake, and to a certain extend they are, but we also like to forget that many of the organisation issues traditional business go through also touch SaaS organisations the same way. Challenges like team silos, lack of innovation, sub-optimized processes and so on.
In all the startup jobs I had in the years I worked in London, I realised most companies don’t really know what problem they’re trying to solve for their customers. On paper, they do: they have a vision, data and a strategy; but in reality, different teams within a company will often have a siloed vision of who the customer is and what problems they’re solving for them. There’s a lot of data out there to figure things out, but it’s often trapped in multiple spreadsheets and tools.
As a Head of Growth, focused on improving retention, I remember having to log into all the tools one by one to figure out what people were doing with the product and what they were saying: Zendesk, Intercom, NPS tools, you name it. Here I was: working for a company aggregating data for their customers, but still struggling to connect the dots when it came to customer stories and I thought: why is it so hard to get a little bit of the data/ browse what people are saying all in one place?
I didn’t even think about deep analytics at that stage. I just wanted to unify all that fragmented data into one place, so teams could find meaning in it, and have a better idea of who their customer was. I also thought it was important to create something accessible by all teams, and used by everyone in the business, not just the product, growth or customer support team.
At the time, I was discussing these ideas with a colleague at Geckoboard, who later became my cofounder.
NomNom was born!
I remember you initially interviewed a lot of product managers and their team. Can you tell me more that process, and how you made sure you were not building ‘another tool for products managers’?
The initial product discovery work was very intense. We made a ton of mistakes around the questions we were asking. It is very easy to formulate questions that lead your interviewees to tell you what you want to hear. It was only when we change our approach to using jobs to be done interviews that we actually started to get a bit more clarity around the specific problems we could actually focus on.
One of the interesting parts of working with PMs in the discovery process is that you either talk to people who go straight to the solution they think we should build or completely the opposite, we had great PMs tell us, “if I was you this is the info I would find helpful, so this is how things actually happen and my workflow”. They would even articulate the job they were trying to do for us as they would write it themselves. Product managers are in nature very helpful and talented people so it is always exciting to talk to new teams and discover their challenges.
This is an ongoing process for us and it does get harder when you already have a product in the market. It is difficult for people to unseen the solution so the interviews are harder to do without having some natural bias already in there.
I basically had to become my customer and learn how to build a product by doing it and being genuinely curious about the problem. I didn’t have a product background, although I have built small products in the past as side projects. In this case, I learned tons by just interviewing product managers and listening to their problems. Then it was all about learning how to lead an engineering team and of course, raise money, recruit a team, get the product in the hands of users and so on. I had to become another version of myself. And I made all the mistakes possible in the process! In every retrospective we do at NomNom, I always remind the team that everything that happens here is my fault… and as long as they’re open about their mistakes too, we can make progress.
My days are normally filled with a combination of any of the following, I would do a bit of customer support, work on our acquisition strategy, update investors, meet with the engineering team, do demos, test new features, writing releases and everything in between. As we grow the team, my role will evolve but as of now, I’m still enjoying being part of many areas of the business.
I’d tell her to ‘chill out!’. I remember I used to be so nervous, in a constant rush thinking about the skills I needed to develop, how to develop them and get that ‘T Shape’ profile and so on. Like most people, I assumed my first few roles and experiences would be defining. But this is based on the assumption the world isn’t changing and that today’s jobs will still exist tomorrow, and that things are linear; but they aren’t. I started my career managing a big public project with the government of Venezuela and here I am running a data startup! In the end, you can’t ‘plan your career’; you can decide on the areas you want to focus on and develop, but you might end up in a role that doesn’t even exist today. You need to embrace that.
So I would definitely tell myself: ‘Stop overthinking; just try to be the best at what you are doing today. Trust that things will come together and make sense in the end.’ Discipline and being open to opportunities will ultimately take you where you want to be.
The world is filled with incredible talent and restricting your options to one location can be a disadvantage. We believe that best working environment is the one that lets you be where you want to be and build your routine in a way that makes you genuinely productive. No commuting hours wasted hence less stress for everybody.
Our team is distributed between London, Prague, Lisbon and Porto at the moment and it works well for us.
Communication is always a challenges, whether you are a remote team or not. In our case, we created a set of principles and simple rules that help us make sure we are on the same page. From typical things like daily stand ups, retrospectives and all hands about the business in general to more quirky things like the 5-minute rule, which is that if you spend more than 5 minutes explaining something in Slack you have to jump on a call.
I think it helps to understand what each channel is for. Slack is great for quick questions when people are working on something together or need to leave quick updates but Google docs are better for in depth discussion that will be later be taken into a call for example. Documenting things as we go so we can make our calls more productive is something that has helped us a ton.
We have 1-1s every month with every team member and retros every 2 weeks. Those are simple and well known mechanisms to keep communication flowing, we just have to be good at understanding if we are running them as effectively as we can.
One thing that really helped me is to look at my inbox only twice a day: I clear everything in the morning, then I only check it again when I’m done with my big tasks. I used to be very reactive and open an email as it came in. Now I batch things and it makes my life so much easier.
I also rarely do face-to-face meetings; I prefer calls. Even if the person is in the same city, I would prefer calling; commuting is a time and productivity killer, especially in London. I think face to face meetings have their place of course, but most things can be solve via emails and calls.
Another little trick I use is to create fictitious timelines for things. Otherwise called the Parkinson’s Law, that says: “work expands so as to fill the time available for its completion”
The rush and urgency to finish work in a specific period of time can be a catalyst for productivity. I haven’t invented any of these concepts, I just tried to implement the best way possible the techniques that has been proven as helpful.
Our stack is very simple, Trello for product and project management, Slack for general communication, Status Hero for daily standups and Retrium for retrospectives. We use Zoom and Hubspot for calls and demos.
For customer intelligence we use NomNom for feedback management and research, Amplitude, FullStory and Mixpanel for analytics and Intercom for customer support. We have of course many many tools for development and so on but when it comes to daily tools for keeping the team organised we try to keep them to a minimum and all focused on supporting either decision making or communication between us and our customers.
I’ve learned over the years that good processes are always more important than tools. We tend to focus on designing the process first and then looking for the tool to support it otherwise you are always limited to what the tool can do for you.