Interviews in Space: Meet Jelmer Borst, Platform Product Manager @ Picnic Technologies
I had the pleasure of connecting with Jelmer after listening to his talk with Abi Noda on the Engineering Enablement by DX podcast.
We shared experiences and stories, and I realised we have a lot in common when it comes to our thoughts on Platform Products. However, his background in Aerospace Engineering is much more fascinating than my half Creative, half Economics background.
He kindly agreed when I asked him to join me for a virtual coffee and be my first guest interviewee in the Newsletter.
Let's dig in.
Tell me a bit about yourself - what got you into Platform Product Management?
First of all, let's define the word platform. In my view, there are two streams of platforms: On one hand, you have the B2B approach, like Uber, for example. A Marketplace connecting Supply and Demand without a Sales team, and the Internal Platform engineering approach, which is how I define the Platform product at Picnic Technologies.
In terms of my role, I started working at Picnic Technologies out of University, primarily because I wanted to work in a place that went faster. After studying Aerospace Engineering and designing planes that may not launch for 50-70 years, I craved a faster-paced job.
I found my way to Picnic when we had a team of 40 people, and the concept of a Product Manager didn't exist. Instead, we had a group of people, including developers, operations, and analysts that basically operated as a single team.
At a certain point, the company expanded to Germany, and I got to work on Payment and Finance products. As money is always a very sensitive topic for customers, one of the things we did early on was investing in automated testing. This got me thinking about what it means to build and deploy software faster. How can we have higher quality in our projects? I recall receiving the Accelerate book from a team member, devoured it in a day or 2, and loved it!
As our product grew, we focused on transitioning engineers passionate about solving these problems into different Product teams, which I now support. Our primary focus is accelerating teams and making processes more self-service these days, ranging from infrastructure, to developer tooling, to analytics, and more!
As Jelmer grew in his role, I was curious about his advice to Platform Product Managers on foundational topics like Product Vision and Product Strategy.
What advice do you have for folks trying to set out the overall product vision and strategy for the Platform team?
STOP BUILDING!!!
Or at least: resist the urge to go head-deep into implementation-mode. When starting a new project, it's essential to stop and have conversations with your stakeholders to understand the overall strategy and goals of the company. There are 3 categories here: what does the board expect from you to deliver value on? What are the goals of the other product teams? And what are your users - back-end, front-end, QA, data scientists, … - struggling with?
Secondly, often we think more or better tools will solve the problem. Yet, rather than immediately jumping into building a product (or buying that shiny tool), take the time to assess what existing tools are available to solve these problems and what your users need.
Please refrain from thinking that building new tools will solve all problems. Make adoption a part of solving the problem.
When building tools for engineers, remember that some are experts in their field and have high standards for the tools they use. However, it's essential also to consider the needs of an average user and not just the experts. This can be achieved by understanding all users' struggles and pain points. A good way to think about this is the concept of ‘building for the 99% developer’.
By combining that expert knowledge with actual user needs, you can build tools that are valuable to a larger audience. In this process, it's crucial to balance addressing current struggles, pushing boundaries, and making step changes. However, solving everything for everyone at once is challenging and leads to slower iteration speed, especially for larger companies.
Instead, start with one or two teams and use them as a trial to figure out any issues. Then, roll out improvements to the rest of the teams. For example, you can focus on small improvements that can enhance the developer experience, even if they don't directly affect speed.
We touched on an interesting topic here around who you should build for and what level of adoption you should expect, and I agree with Jelmer on this one. Build for your Early Adopters and Innovators, and the Laggards will come.
Below is a visual of what we actually mean, a concept first introduced by Geoffrey Moore in Crossing the Chasm:
Source: Think Insights
Moving on, I wanted to know how he measures success for Platform Initiatives and how he thinks about Metrics. Yes, we talked about the DORA Metrics too.
So you have all these strategic initiatives - how do you measure success? What are the key metrics in your area?
That depends on the company and the context, but at a high level, you have the DORA Metrics and the SPACE Framework. So companies will blindly start optimising for those, without thinking why, the underlying driver, or if that’s really their challenge to solve.
For example, you take Deployment Frequency from DORA and say, " Oh, we should deploy more often. Then you're optimising for the metric, but what are you really gaining? You may be lucky and start seeing some improvements, but there are better ways to think about Metrics.
What is really helpful is to focus on the Northstar Metric of the company and how you can contribute to that from an Engineering point of view.
Instead of optimising for metrics like deployment frequency or the number of bugs, break down the underlying metrics and identify the drivers. Visualised below:
Source: Jelmer Borst
Then, experiment with improving those drivers, such as improving test automation, and measure the results over time.
This process requires patience, as changes may take time to be seen, but it is a more effective way to improve overall outcomes.
It's a very data-driven and pragmatic view of Metrics, one that I fully share. Unfortunately, it's extremely easy to fall into the trap of just measuring the DORA Metrics, which ultimately can become Vanity Metrics.
The most important thing is to have multiple data entry points and break down your Metrics to understand the overall impact.
Finally, in the last part of the interview, we settled the ultimate debate on whether or not a Platform Product Manager should be technical.
One last question: Does a Product Manager need to be technical to work in the Platform space?
I favour ‘Camp Yes’, which does not necessarily require you to be a software engineer, but understanding technical concepts is essential.Otherwise, it becomes difficult to identify your users' struggles.
When hiring Product Managers for the Platform teams, be cautious not to hire another software developer. Instead, the ideal candidate should have a background in software engineering and at least a year of experience in product management or a customer-facing role. This is a very effective combination for companies, but also hard to find.
And finally: do you have any Books, Articles or a Podcasts recommendation?
Podcast: Engineering Enablement by DX
Books:
Good Strategy, Bad Strategy, Richard Rumelt
The Hard Thing About Hard Things, Ben Horowitz
Principles of Product Development Flow, Donald Reinertsen
Ask your developer, Jeff Lawson
Factfulness, Hans Rosling
Articles:
https://future.com/software-development-building-for-99-developers/
https://martinfowler.com/articles/developer-effectiveness.html
https://cutlefish.substack.com/p/tbm-4151-why-goal-cascades-are-harmful?s=09&sd=pf
You can catch Jelmer speaking about How to Apply a Product mindset to your Platform team at QCon on the 29th of March.
And tune into his chat with
here .Thanks Jelmer, again for agreeing to be my first guest on Interviews in Space - it was an absolute pleasure to talk to him, and I am sure you will find his insights valuable.
See you next Friday!