Eric Lammertsma is Head of Product at Docfield, a contract management lifecycle platform that simplifies contract and document generation and compliance. After completing an internship at the Yale School of Medicine, he launched CrimsonBase — a user-friendly, intelligent genetics software. From there, Eric founded Pixplicity, a creative tech agency, where he later transitioned to Head of Product. Before his current position at Docfield, he served as Head of Product at Tilig.
In our conversation, Eric talks about how the same three elements of creating a hypothesis, performing an experiment, and getting results based on that apply to both science and product management. He shares his background in genetics research and how that prompted him to become the founder of a digital product. Eric also talks about the iteration process and the importance of emphasizing it wherever possible.
I started my academic career in biomedical sciences. I took some entrepreneurship courses and business courses during my studies, but working at a lab at Yale is actually what really kick-started my career in product management. I was putting together a collection of macros in Excel to do genetics work, so I was essentially trying to make genetic software without a computer science degree.
My colleagues in the neighboring labs started coming to me with all these requests like, “Could you make this? Could you make the macro do that?” That made it very clear to me that there was an opportunity for this kind of genetic research software. Shaping the requirements for that software, understanding what it actually needed to do, and getting to the root of which problems it needed to solve were the primary drivers that got me into product management.
I founded a company called CrimsonBase to solve those problems, and I understood that coming straight out of university, I was not the foremost expert on genetic research. I relied heavily on my prospective customer base for information on what they were running into in their daily lives and in their work, as well as what would be the most valuable for them to be able to do better research.
As a product CEO, I was hitting the pavement every day to talk to labs in my own university and neighboring colleges. I lived in the Netherlands at the time, where, fortunately, the density of universities was quite high. I could just travel around to these universities and talk to people. That gave me a very holistic view of the market and understanding I need to build, while also allowing me to wear that sales hat.
I very much do. In the very beginning, it was second nature to want to prove my assumptions. As a PM, you make assumptions, build prototypes to test them, and then go through a validation process. In science, it’s the same thing — you form experiments based on hypotheses, and based on that, you get results. Those are the same three elements.
When I was building the software and the company itself, I needed to ensure that I wasn’t just building something that I, a fresh-out-of-university kind of entrepreneur, felt I needed. Even more so, I needed to make sure that I truly understood the real needs of the market. I talked to people who had much deeper expertise than me, were much smarter than me, and also had a humble mentality.
In talking with a lot of labs to gather information, I realized that these folks were so eager to give me answers that it seemed like nobody in the market had been talking to them at all. They were so excited to tell me what their problems were, what thoughts they had, and what improvements we could make to do better research.
To some extent, I think the people working in these labs thought of us as a software company with the power to change their lives in the lab. I decided to make an open beta to get as much feedback as possible. They embraced us very much. Of course, we made some mistakes, but there was an academic atmosphere around the beta — there was a willingness from our users to accept the mistakes because nobody was paying for it. Everybody was just happy to be a part of the process and to see how the product was developing.
When it came time to switch over to monetizing it and putting a price tag on the software, the vast majority of those labs came on board because they already understood and had helped refine the value of our product.
I had to learn a lot by doing. I did a mini MBA, for example, and while things like that are helpful, you don’t realize how much you don’t know until you’re in the driver’s seat of a startup. And this was around 20 years ago when there weren’t a lot of books on product management or product development in general.
What I took away from that experience was similar to what you can read today in product management theory books: customers don’t necessarily know what they want. They know what their problems are, but you have to understand that you’re not building what customers are asking for. Rather, you have to come up with solutions to their problems.
When I was selling CrimsonBase and looking to get into my next adventure, I realized that my favorite part of the entire job was the product management side of it — understanding the market, innovating, solving problems, and shaping and shepherding a new product into the world. So, I founded a company called Pixplicity where I could do that continuously over and over again. It was an agency that provided product management on tap.
In the early days, we heard a lot of things like, “I have this idea for an app. Can you build it?” That worked out well in the sense that it gave us cash flow to start growing, but we really started to pick up speed when we started actually doing product management for our customers.
The first customer I remember having a ton of fun with was essentially the Dutch version of Consumer Reports. They understood what we were doing and came to us with a problem instead of a solution. They said, “We want to map out or somehow figure out how to objectively measure the mobile network coverage in the country from all of the different providers and compare them.”
That gave us the opportunity to solve their problem — not build their idea. We started talking to users about what they found to be most important and what kind of issues they would run into. Most people said, “My phone works great outside my house, but as soon as I’m inside, I get dropped calls and problems.” We started understanding when we needed to map indoor versus outdoor measurements. People wanted to do internet speed tests because they wanted to compare speeds.
So, we started building a solution for them that created these beautiful heat maps across the country showing what the network coverage was between each provider. That way, people could actually compare them and make an informed choice.
Yes, another example is when we did work for ParkMobile. These were the early days of things like QR codes and NFC tags. We were working with ParkMobile to build them a mobile app for parking because, at the time, they were a company that operated through text messages. As a user, you would actually walk up to a parking meter, text the zone number and your license plate, and it would charge you through text. Then, when you left, you would text them again, which ended the parking meter.
We turned all of that into an app. One of the things that ParkMobile hadn’t been thinking about was what to do when a customer shows up at one parking meter but doesn’t have the app. To solve this, we implemented NFC tags on all of the parking meters throughout the country so that all users had to do was tap their phones on them.
Further, Google was doing something really interesting at the time called Instant Apps. It downloads a portion of an app to a person’s phone without the need to install the app itself. That way, someone can interact with a service without going to the app store and downloading it completely. We integrated this technology into ParkMobile so that a user could tap their phone on the parking meter, and, whether they have the app installed or not, ParkMobile pops up. That drastically reduced the barrier to entry for new customers and increased their acquisition rate.
In theory, product management says that you should always iterate on a product, and I agree with that. You should try to create that opportunity as well if you can.
In practice — and especially through my agency experience — I’ve noticed that you don’t always have that opportunity. For example, take the Taylor Swift Eras Tour concerts where everybody in the crowd has glowing wristbands that sync and light up across the stadium. They go off in fun patterns based on where you’re sitting and it’s really cool. That’s something that you can’t practically iterate on — it’s a one-time launch.
For OnePlus, we showed the first VR product launch using 360-degree video on YouTube. YouTube didn’t officially support that yet, which was a really interesting challenge. We did all of these crazy things that we had one opportunity to get right. And when you have a product like that, you only know what’s going to work for sure on the day that you do it. Those are a little bit trickier, but just when you can iterate, always iterate.
Something I’ve subscribed to over recent years is a version of Marty Cagan’s model of having a designer, an engineer, and a product manager. That’s something I was already doing before it was written down by Marty, and I like that he set it in stone for the whole product management field.
I modify that depending on the circumstances because sometimes, you do need a subject matter expert on that team who isn’t a designer or an engineer. When I was working at CrimsonBase and building genetic software, for example, we needed somebody who understood the intricacies of doing genetic research. In general, as you work on developing something specialized, your engineers and designers are going to become experts in that domain.
Having worked in a startup space, I don’t actually encounter big problems with cross-functionality because departments in my spaces just aren’t that big. And reaching across the aisle to talk to somebody in marketing is as quick as just sending a Slack message. Still, that doesn’t take away the fact that some people just aren’t very strong communicatively, so it takes time and nurturing to build those good communication skills.
I think that the primary thing that I look for in people is passion — both about their jobs and their areas of expertise. Or even if they’re not experts on it yet, it’s the fact that they’re passionate about a certain thing. I look for that over experience and education.
A combination of those three things is great, but if I had to choose between somebody who’s not passionate about what they do but has a ton of expertise and someone who’s passionate about it and doesn’t have that experience, I would pick the passionate person every time. They will surpass the other person in that they’re going to make it their mission to understand their jobs.
Further, people who are passionate about what they do are much more communicative as well, which is incredibly important in a cross-functional team. They’re trying to learn. They’re trying to get everything that they need, and there’s often less of a barrier to them reaching out not only to ask for help but also to provide help to others. Because they’re going to be very excited that they can provide some help to somebody.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
To help demystify stakeholder management, you can use tools that introduce a structured approach for your product team.
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
Learn more →
