Aislinn Wright is VP of Product Management at EDB, the Postgres data and AI company. She began her career at IBM, where she started as an associate project manager and later found a passion for product management. Aislinn worked as a product manager for various data services in the IBM Analytics and Watson & Cloud platforms organizations before joining the product organization at EDB.
In our conversation, Aislinn talks about pillars that have shaped her product strategy, including open-mindedness, always asking why, and surrounding yourself with people you look up to. She also talks about how she effectively navigated change as EDB grew from a few hundred employees to almost 4x that today.
Three principles have helped me tremendously in navigating technical subject matter. The first is the practice of asking “why.” Back in school, we were always challenged not to have the answer but to be able to find ways to uncover it. I think about that every day. It helps me step back and understand the critical reasons behind decisions. I keep that close to my thought process as I think about product, strategy, and where we’re going.
Second, I’m comfortable with being uncomfortable. There are a lot of unknowns in product management, especially when you’re coming from a less technical domain. I learned early on to be aware of what I do know and feel comfortable with, while also being OK with the fact that there’s a lot I don’t know. Having that self-awareness is critical. I’ve overcome some of the unknowns through research, asking questions, and aiming to learn as much as I can every day.
The last piece of advice is something someone shared with me early in my career: surround yourself with people you admire. Be around people who are smarter than you. This has particularly helped me learn many skills from people with different backgrounds.
About a year and a half ago, our product team was working on a feature for our cloud service. There were a couple of different paths we could take, and the feature itself was centered around read-only replicas. The idea was to read from a replica of the database in order to leverage the replica for disaster recovery or for business intelligence use cases. It was helpful that I didn’t carry a lot of context about how people use this feature, which reduced potential bias.
I tried to think about it from this open-ended perspective and did external competitive research. I talked with a lot of customers about their use cases, and it helped that I didn’t come in with an opinion based on my background. There were two ways that we could have implemented this to satisfy the different use cases, whether it be disaster recovery or querying data from a database that’s not the customer’s core transactional system.
What particularly helped was marrying competitive research with customer data to understand the biggest pain points. We were able to meet the needs of what we heard from our prospects and customers, and a lot of that stemmed from my willingness to do the research instead of having a predefined opinion.
It came back to one of the principles I mentioned earlier, which is remaining comfortable with being uncomfortable. Having self-awareness around what I do and don’t know was important, too, especially in customer conversations.
At one point, I was working with one of our customers who ran databases at scale for a hospital system. I met pretty regularly with that team on site, and I remember walking away from some of the conversations with a new set of context. I quickly understood I didn’t have to have all the answers, but it was important for me to have the motivation to find and understand them.
If I’m learning something new, I like to apply it to something that I can relate to. I think about references that I know and connect to a bigger picture. That way, when I’m talking to customers or prospects, I can understand how something deeply technical actually relates back to the very initial problem that they’re trying to solve. That framework for applying references is very helpful for making important connections between deeply technical concepts and how they apply in a use case.
The last piece is leveraging visuals where possible, especially when I’m learning new things. These days, everyone has constant emails, texts, and notifications. It’s easy to miscommunicate, so having visualizations is really important for me, as well as vetting the information with other people to ensure I’m understanding correctly.
One important factor is outside influence. Changes in our leadership team have greatly impacted our product strategy in this way. To a degree, everyone encounters this as an organization scales, but I specifically came into my current role from being an IC product manager. Five years later, I now manage a broad team of product managers and define product strategy. It’s been interesting having both vantage points.
There are, surprisingly, a lot of similarities between these two roles. Some things never change, such as seeking feedback from the market, prospects, and customers, and I appreciate this process now more than ever. It’s not the be-all voice for everything, but it has been an absolute cornerstone for our growth.
AI has also introduced great ways for us to collect this feedback. For example, we use NotebookLM to ask honest, daily questions around customer conversations and feedback. That helps us inform our planning and it’s been exciting to see how it’s made our process easier.
On the flip side, one thing that has evolved is the breadth of scope, especially in going from 200 to 1,000 employees. Still, we continually invest in many products and capabilities that have been developed by EDB years ago. How can we help them manage databases at scale? How can we help them leverage Postgres for a broader set of use cases? This speaks to the skills and the talent growth that we’ve had, as well as how the product has evolved to address more customer challenges.
One thing that’s definitely changed is the size and scale of the team. We’ve grown considerably, and I’ve had the opportunity over these five years to interact with many different types of product managers. The team has matured, in a way, just from having such a diverse skill set within it.
When I first started in product management, I was naïve about what makes a good product manager and often held a belief that it was a very specific type of skill set. Being a PM is probably the most diverse role out there for someone with this skill set. I’ve come to appreciate having such different points of view and voices at the table, as well as how this has contributed to the maturity of the organization. I’ve challenged my perception of what makes a great product manager, and in some cases, I’ve been surprised.
For sure. It’s funny because, even looking back four years ago, I used to look for skills that were similar to mine. I’ve found that it’s actually the opposite now, especially as I’ve worked with more PMs. I look at how the broader teams can complement each other, and sometimes, that’s very different from person to person. There are some constants in terms of core principles, but by and large, I would say that my view on hiring four years ago was substantially different.
I’m often blown away by the people I interview. They’re often much smarter than me in some ways and have many strengths that I don’t currently possess, and that’s something I love so much about this role. I’ve really embraced it.
I think it’s very important to be yourself, 100 percent of the time. This is especially important if there are new leadership or team changes, but this is something I never consciously thought about. Everyone has different points of view, and they’re going to come in with different goals in mind. Change is to be expected — I can’t predict what’s going to change, but I can accept that it will happen. I can control myself and who I am, so I’ve always wanted to stay true to that.
This particular mantra has helped me get through periods of hard or ambitious change. I try to remind myself that there are benefits to all the experiences I bring to the table. I want to bring that with me, be myself, and not overthink it.
A piece of advice specific to product management is to stay open-minded. I sometimes find myself pausing before reacting to things or leaning too heavily on saying, “We tried that already, and it didn’t work for these reasons.” Instead, I now shift toward a more open-minded perspective. People who have been in the same company for a long time can find this hard to do, but it’s a very important practice.
More generally, balancing personal priorities is also really important. Any sort of change, hyper growth, or transformation can be emotionally taxing — it’s hard on any organization or individual. It’s crucial to know your personal priorities and make sure you have time for them. For example, I love working out. It’s my sanctuary and how I reduce stress. Exercise and prioritizing family time are two things I will never regret dedicating time to.
Overall, I like to remind myself to put myself first. I ensure that I prioritize the things in my life that are important to me to help me through change, and I’d give that same advice to anyone.
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?
Between ignoring your design team and micromanaging them, there’s a sweet spot where you all can deliver great results.
Ryan Poppa, Senior Director of Product Management at DNSFilter, shares the importance of not being afraid to say no to customer feedback.
Whenever I open PM groups on Reddit, Facebook, or WhatsApp, I see people asking the same question: “Will AI take my job?”
Ylang Nguyen talks about how she has helped teams work through the operational and cultural challenges that come with acquisitions.
Learn more →
