My day starts with standups. I’m not working on a product at the moment, but I’m overseeing all the product development. So at 9:30 AM, I’m checking in on different teams. This gives me great insight into different team’s habits and what processes work for them. Next, I’ll have a sit-down with Adam, a tech lead at Cytora who I’ll be setting up a new team with soon. He recently did research into how different companies build machine learning systems at scale, so we talk through which ideas we think will work for Cytora. I usually forget to pack my homemade lunch, so I quickly run to the Whitecross market to grab something. In the afternoon, I sit down with the team to talk through the interview process for some new roles and do some talent sourcing. Most days I catch up with our CEO Richard to make sure I’m working on the most important things.
I learned to code before I got to Uni. When I was there, I realised I liked building stuff with computers more than physics. By the end of my degree, I’d started doing freelance web development and worked at Decoded in the summers developing their education products.
Out of Uni, I decided to work for Head London, a digital products and services agency over a startup. I worked in the labs department hacking all types of tech: IoT, wearables, nearables, VR and google glass (remember that!) to name a few.
What I didn’t realise was how much exposure I was getting to the best practices of product development. When I left for a friend’s startup, I took that with me. That startup, a marketplace for translators, never really took off. After five months, I was looking for a job when a friend at Cytora gave me a call. I joined as an engineer but ended up becoming their first Product Manager.
“I learned to code before I got to Uni. When I was there, I realised I liked building stuff with computers more than physics.”
The move from Knowledge Engineer to PM coincided with a pivot for Cytora. We’d realised the product we were building had a small market and wasn’t as good or as feasible as we thought. We needed to consider some more high-value alternative industries, instead. So, the founders and a few select employees (myself included), knocked on the doors of insurance companies in London and hedge funds in New York, figuring out where our technology had the most value. This shuttering of product development and the simultaneous need for customer development lead me to assume the role of PM. At that point, we were devouring books on customer development and early-stage product discovery and ultimately decided on insurance as our vertical market.
I think for the most part it has been invaluable. For a long time at Cytora, I was PM’ing our API, a highly technical product with no visual interface in the traditional sense. I’d built these as an engineer, so I was pretty well placed to work with it. That, coupled with what I half-remembered from statistics at University made me a good fit to become the first PM at Cytora.
At times, you do succumb to solutionising, and for someone who loves to make things, it can be hard to let teams find the solution on their own. Eventually, I’ve become much better at it though, as I discover more valuable things in my work besides suggesting solutions to help my team along.
“...for someone who loves to make things, it can be hard to let teams find the solution on their own.”
Yes. I try to build something, however small, once a month. I write snippets at work to help me test API responses when I’m QA’ing, and if there’s talk of a new Google cloud product at work, I might spend a weekend trying to build something with it. I haven’t built much of use, it’s more to keep me sharp. I did build a nifty email interface to the Risk Engine one weekend, which I might put in front of a customer to see their reaction. I could imagine it being pretty handy for big enterprises who don’t want to build a large API integration.
Communication is the biggest thing for us, both verbal and written. At Cytora, all the big projects demand well-understood requirements. It’s easy for something to be well understood by one person, but it’s hard to have a team understand something identically. That’s the power of clear, concise communication.
Typically, I don’t do an agile pop quiz. I might ask a "Scrum vs Kanban" type question, but I'm looking for someone that knows the concepts well enough to talk about when they do and don’t apply.
“It’s easy for something to be well understood by one person, but it’s hard to have a team understand something identically. That’s the power of clear, concise communication.”
It would probably have to be a small project I did at Head: I modified the open source designs for the Google cardboard to fit on the packaging of a 24-can pack from a popular cola brand. I presented this design to a member of their innovation team, demonstrating how someone could buy a pack, and pull the VR headset out of the packaging. We never heard back. Six months later, the same company released a swish video demonstrating the concept. Coincidence? Who knows. But, as they say, imitation is the sincerest form of flattery.
One of the great things about Cytora is that we only hire people who are better than us. I’m not sure I’d get hired as a PM today, because every new hire raises the bar. We have some exceptional product people here today, in design and product management. I learn new things from them every day, and that's how I continue to improve myself as a Product Director.
“One of the great things about Cytora is that we only hire people who are better than us. I’m not sure I’d get hired as a PM today, because every new hire raises the bar.”
If I had to point to people outside of Cytora, I’d pick out Gibson Biddle and Bradford Cross. Gibson has done an incredible job of sharing stories of his success and failure at Netflix and elsewhere and is a constant source of inspiration. Bradford’s thoughts on how to build successful AI startups are foundational at Cytora—his observations of failure modes ring true for sure, and I’m right now updating our strategy to align with his thinking.