The 129th episode of Datacast is my conversation with Diana Hsieh - the Head of Product and Co-Founder at Correlated.
Our wide-ranging conversation touches on her undergraduate experience at MIT studying Economics, her early career in investment banking, her transition to VC at Norwest Ventures, her move to product management at open-source startups Cockroach Labs and TimescaleDB, her current journey as the Co-Founder and Head of Product at Correlated, the rise of Product-Led Revenue, her perspectives on modern product management for early-stage startups, and much more.
Please enjoy my conversation with Diana!
Listen to the show on (1) Spotify, (2) Google, (3) Deezer, (4) RadioPublic, and (5) iHeartRadio
Key Takeaways
Here are the highlights from my conversation with Diana:
On Her Education at MIT
I mostly grew up in Orlando and attended public school. My upbringing was simple and middle class. It's not common for people from Orlando to go to MIT, but somehow I managed to get in and that's how I ended up there.
People always ask me why I chose to go to MIT, and the truth is, it was simply the best school I got accepted into, so I made the decision to go. I did have some concerns about attending such a technical school because I always knew I didn't want to be an engineer 24/7.
I didn't want to spend all my time coding or be an electrical engineer. Instead, I wanted to pursue something tech-oriented but more on the business side. So I had reservations about going to MIT and wasn't sure if I would fit in. That's why I ended up studying economics instead of computer science or electrical engineering.
When I arrived at MIT, many of the students studying computer science and electrical engineering had been immersed in physics since a very young age. I didn't feel like I belonged to that culture, which is why I ultimately chose to study economics.
On Her Internships
I believe that most people who know me would not be surprised that I'm a product manager, as I tend to apply product management principles to various aspects of my life, not just work.
During my early years as an undergraduate student, I researched different career paths and decided that I wanted to become an investment banker, primarily because of the higher salaries in that industry at the time. I was determined to join a top-tier investment bank and earn a significant amount of money.
To secure internships in the field, I had to prepare extensively in advance. This led me to work at Hungry Fish Media while still studying. Balancing this part-time job with my coursework was challenging, as I constantly felt tired. Unfortunately, I even fell asleep at work and faced repercussions. However, my understanding boss, who has since started his own startup, sympathized with my situation and advised me to prioritize sleep before coming to work.
This experience taught me a valuable lesson about responsibility and understanding my own limitations. Despite the challenges, I learned a great deal during my time at Hungry Fish Media, which marked my first exposure to a startup environment. Additionally, my internships at Morgan Stanley and other companies provided me with valuable on-the-job learning experiences.
One significant learning experience occurred during my internship at TSMC, where the predominant language spoken was Chinese. Although my proficiency in reading and writing Chinese was limited, this presented an opportunity for growth and learning.
Overall, I thoroughly enjoyed my internships and gained valuable insights from each of them.
On Being An Investment Banker at Morgan Stanley
If I were to think about my biggest learnings, I can group them into two categories.
The first category is related to work, specifically technical ability. Investment banking taught me to set a high bar for what I consider good quality work. In that environment, even small details like aligned pictures or correct fonts were important and would be criticized if they were not done correctly. This experience pushed me to have higher expectations for myself and not settle for subpar work. It was one of the valuable things I learned there.
However, the biggest lesson I took away from my time at Morgan Stanley is the importance of company culture. Despite actually enjoying the work and the opportunity to meet CEOs of public companies, I left Morgan Stanley early because I realized that the culture there was not aligned with what I wanted for myself. The environment stopped being enjoyable, and it wasn't supportive. Leaving early exposed me to some unexpected challenges, as the company's support changed once I became unhappy. This experience taught me the significance of company culture after spending a year there.
Another important lesson I learned is about people and how the business world doesn't always consist of good people, despite what we would like to think. I encountered situations where people took projects away from me, acted aggressively, or expected me to cover for them while not reciprocating the favor when I needed it. There were also instances where bosses would haze me to some extent. It made me realize that people are people, and even if a company has a good reputation, the people within it can still exhibit negative behaviors.
Interestingly, when I applied for investment banking, I initially wanted to join the tech group. Despite warnings about the long hours associated with that group, I still chose to be a part of it because I had a genuine interest in technology. I didn't want to work in other areas like power and utilities. Once I started working in the tech group, I discovered the exciting world of startups and their innovative contributions to various industries. This experience solidified my decision to pursue a career in the tech industry.
On Transitioning Into Venture Capital
I believe there are several reasons why a career in venture capital is more enjoyable than staying in banking. One of the main reasons is that many VC firms tend to recruit directly from investment banking. This is where they find individuals who have been trained in using Excel, creating PowerPoints, and thinking about business strategy. I was recruited because of my background in investment banking, but what particularly interested me about venture capital is the power dynamic.
In finance, there is the buy side and the sell side. On the buy side, you have more power because you have the money to invest in companies. On the sell side, you are trying to convince companies to use your services. Personally, I prefer the power dynamic on the buy side, which is why I wanted to transition into venture capital.
During the recruitment process, I also considered private equity. However, after one interview, I realized it was like banking on steroids, which I did not enjoy. I did not want to go through the same experience in private equity. Venture capital, on the other hand, works with smaller companies, and I had always known that I wanted to start my own company at some point. So transitioning into venture capital seemed like a better fit for me, as it would bring me closer to startups.
I chose to join Norwest, a great firm with a unique culture. Back when I was there, they had more of a mentorship model, where associates could climb the ladder. They had a strong reputation in enterprise software, which was why I was drawn to them. They had invested in many successful enterprise software companies. I genuinely liked every partner I met at Norwest.
Norwest mainly focuses on series A to C, but they also do late-stage investments. They have a large fund and a growth equity fund, making it a comprehensive group. I believed it was an excellent place to learn the basics of venture capital.
On Her Learnings as a VC
I often find it amusing to read my past blogs. I don't like taking them down because, personally, I find it interesting to see how much I've grown over time. However, when I was an associate at Northwest, I admit that I didn't have a thorough understanding of what I was talking about. As an associate, you get exposed to many startups and trends, so while I don't believe what I wrote was necessarily incorrect, I now realize the nuances involved in everything, especially working at a startup. In venture capital, you tend to make broad statements, whereas at a startup, you have to figure out how to actually implement those statements. It's a completely different perspective.
One of the biggest lessons I learned at Northwest was the importance of networking. Every company I encountered was through networking. In fact, I got my current job through networking, which we'll discuss later. Meeting the right people and building a strong team are crucial in this field, so networking is definitely the number one lesson I took away from my experience as an investor.
Back then, blogging on WordPress and even earlier on Tumblr were like the initial versions of what people now call LinkedIn influencers. As an associate, I realized that the only way to get your name out there is by sharing your thoughts and the things you've learned. That's why I started running a blog. It not only helped me organize my thoughts and reflect on what I've learned, but it also served as a way to gain visibility. Sometimes, people would approach me and mention that they had read one of my blogs about the essential slides needed in a pitch deck, which they found helpful. This was the main reason why I decided to blog.
On Joining As Cockroach Labs The First Product Hire
I had previously mentioned that there were various reasons why I wanted to become a startup founder, but I wasn't completely sure if I was ready for it since I had no prior experience.
Becoming a startup founder without any experience requires a certain amount of ego and hubris, which I lacked. So, I made the decision to join a company where I could learn about building a startup from someone who was already doing it. I wanted to move back to New York because my family was on the East Coast, and constantly traveling from the West Coast to the East Coast was becoming exhausting.
I had a list of interesting companies based in New York that I had encountered during my time as an investor, and that's how I came across Cockroach and met the founder. I saw it as an investment opportunity and liked the company, so I simply asked if there was a job available for me.
One of the reasons why I decided to leave the venture capital industry, and why others might choose to do so as well, is that at the lower levels of venture, and even at the partnership level in many ways, you're essentially doing sales. You have to network and sell yourself and the fund to startup investors, who are essentially the customers.
During that time, I felt that sales wasn't necessarily my strong point, and in order to be chosen by founders, I needed a stronger background and more operational experience. That's another reason why I chose to leave. I didn't feel that staying in venture capital longer was aligned with what I was looking for.
Realistically, the venture capital industry offers a high salary. However, I realized that the longer I stayed and waited for promotions, higher salaries, and raises, the more difficult it would be to transition to a startup. So, I made the decision to move to a startup before I became accustomed to a high salary and experienced lifestyle inflation, which would make it challenging to return to a startup.
That's why I decided to leave the venture capital industry early on.
On Transitioning Into Startups
I believe that the most important thing, if you want to transition from venture to a startup, is to join a startup where the founder is involved. This is because it is the easiest way to get in.
If the founder perceives you as intelligent, they will find a suitable role for you. However, many venture professionals are unaware of what they do not know. Therefore, when seeking a role at a startup, it is crucial to understand your own strengths and what you can bring to the table.
For instance, when I joined Cockroach, I recognized that my strengths lay more in product marketing and positioning. As a VC associate, I was always considering how to position a company, who the target market was, and the market opportunity. These skills are more relevant to business analysis, strategy, or product marketing.
On the other hand, I knew that I was less skilled in product management. Therefore, for many associates who aspire to immediately become product managers, it can be challenging without a technical background. It is important to know where your strengths lie and search for a role that aligns with them.
I know several associates who left and joined startups, eventually transitioning into product management roles. However, they often start with unusual titles such as chief of staff, special projects, or business operations. Over time, they transition into product management by leveraging their strengths in their initial roles.
On The Challenges And Learning Curves as A Non-Technical First Product Hire At Cockroach
I believe that if anyone from Cockroach listens to this, they will realize that I had no idea what I was doing at Cockroach. For me, Cockroach was like a training ground to become more technical.
When I joined, I had no operating experience whatsoever. Therefore, one of the biggest challenges was figuring out how to work with a team. In banking, you typically work with a very small team, where you have an associate above you and maybe a VP.
The same goes for investment in venture. Most deal teams consisted of just two people, so you usually worked with one senior person. However, at a startup, you have to collaborate with various teams such as engineering and marketing, which can involve many people. This was the most significant challenge for me - learning how to work effectively with teams again.
Being non-technical was also a significant challenge at Cockroach because the company was primarily engineering-focused. At one point, the ratio was around 1 PM to 20 to 30 engineers. The product itself was highly technical, and the engineers were building it for themselves. As a result, it was challenging to be taken seriously and prove that I could add value.
To overcome this, I focused on what I did know and tried to leverage my strengths. I focused on areas like positioning, customer conversations, and data analysis to find new insights that could benefit the team. I also resorted to googling topics like building a roadmap and following instructions, which seemed to work well for the first year. However, it was definitely a steep learning curve.
On Determining The Best-Fit Product Strategy
I believe that over time, the idea of using true frameworks, like Scrum or Agile, will sound really bad. Instead, I believe in frameworks for approaching and solving problems. For example, how to determine the most suitable process to use. I don't believe in blindly adopting pre-existing templates because they rarely work. When considering the best-fit process, it's important to be a good listener and encourage team members to propose a process that works for them.
In my experience managing different teams of engineers, each team had its own unique characteristics. Some focused on enterprise features, others on backend stability, while others worked on frontend features. Therefore, it's crucial to understand your team, solicit their feedback, and then determine the most appropriate process. It could incorporate elements of Agile or Scrum, or it could be a custom process. However, forcing a process upon a team doesn't yield positive results.
When I worked at Cockroach, I wrote GitHub issues and used GitHub projects for planning. However, at Timescale, the engineering lead preferred to do these tasks himself, so I didn't write any tickets there. Currently, at Correlated, I also don't write tickets. The approach depends on the team and the expertise of the engineers involved.
Ultimately, I measure the success of a process based on outcomes. Are team members generally satisfied? Are they able to successfully complete tasks? Do they have a clear understanding of their responsibilities? By evaluating these outcomes, we can determine if a process is effective. Even at Correlated, our processes change approximately every six months, as no single process can work indefinitely.
On Being The First Product Hire at TimescaleDB
I switched to Timescale because I perceived it as a different product compared to Cockroach. Cockroach required a more extensive transition, almost like a rip and replace scenario, whereas Timescale was easier to integrate for specific use cases. Timescale had a more focused approach compared to the general database functionality of Cockroach.
One of the main reasons I moved to Timescale was to observe how two different founding teams ran their startups in a similar space. I was interested in learning about different approaches within the same industry.
My role at Timescale was broader compared to my role at Cockroach. While I didn't operate as much as a traditional product manager, I was involved in business strategy, partnerships, working closely with customers and sales.
I joined Timescale during a period of significant growth in open source databases. Both Cockroach and Timescale were open source, and around the same time, Confluent and Elastic had just gone public. This new open source selling model fascinated me.
Cockroach aimed to replace Oracle in some ways, focusing on revolutionizing SQL database deployment. On the other hand, Timescale built upon the solid foundation of Postgres, leveraging its internals and optimizing it for time series use cases. During that time, several open source databases emerged, such as PipelineDB, InfluxDB, and Grafana gained popularity. The landscape was filled with various options and DevOps tools.
On GTM Challenges for Open-Source Projects
I believe that many lessons learned from open source can be applied to all software as a service (SaaS) models. Specifically, when it comes to developers, they prefer not to be subjected to sales pitches. The purpose of open source is to allow developers to test a product themselves before deciding whether or not to use it.
However, the biggest challenge in the market is figuring out how to monetize a product that is offered for free. In open source projects, certain behaviors were observed that did not support a sustainable business model. For instance, Docker is a great technology, but it was not monetized effectively. This was a significant challenge. If you provide something for free without collecting user information, you will never be able to sell to them or generate revenue.
The industry leaned heavily towards the free and open source model, which created difficulties when trying to transition back to monetization. This shift resulted in the alienation of many developers. It is indeed a challenging field to navigate.
On Processing Startup Lessons
I've always wanted to start a startup, which is why I like to blog about certain things. When I learn valuable lessons at work, I get worried that I might forget them. Blogging helps me process and remember those learnings. It's not about gaining a huge following, but rather about my own personal growth.
When I reviewed the questions in advance and re-read my blog posts, I realized that many of the lessons I wrote about are applicable to what I'm currently doing. Being at a startup allows you to witness things happening in real time, and only afterwards can you reflect and understand what occurred. The blog series was triggered by the overwhelming requests we received from the open source community and customers, forcing us to prioritize tasks.
One important lesson I've learned is the significance of focus at a startup. In the beginning, it's tempting to envy other startups who are tackling similar problems or attracting certain customers that you believe you could have. However, trying to capture all peripheral users without maintaining focus will prevent you from building a compelling product for your primary target audience.
This is a valuable lesson I took away from my experiences. While it makes sense in theory, executing it in practice is challenging.
On Cultivating Focus
I believe that this is a challenging question, and it's not something I feel I have mastered yet. I will probably write another blog post soon about it. However, there are two tactical lessons I have learned about how to be more focused.
First, writing down your strategy is crucial. Each quarter, I write down the top three strategic goals we have and use them to guide our work. It is important to regularly check and ensure that we are still executing against these goals. Writing it down helps because at the end of the quarter, if we feel like we have lost focus, we can refer back to our written goals and refocus everyone for the next quarter. Writing things down is incredibly important.
Second, it is important not to make decisions reactively. Often, in meetings with engineering or sales, they may ask for things, and we may be tempted to make immediate decisions. However, I have found that this approach leads to scattered focus. Just because something sounds like a great idea in the moment, it doesn't necessarily align with our strategy. Making decisions in this reactive manner can pull everyone's attention in different directions. Taking the time to sit down and think about things allows for a more focused approach.
These are two practical steps that can help maintain focus.
On The Founding Story of Correlated
I left Timescale because I started feeling that, although different from Cockroach, it was still like being a PM at an open-source database.
I felt ready to start a startup, so I found a gig with one of my old mentors from Norwest who was willing to let me join as an EIR. That's how I funded a year of working on various ideas, conducting user interviews, and learning many valuable lessons.
However, things didn't work out in the end. Tim and John, who were at a different startup, were looking to start something new. Tim, whom I had previously worked with at Timescale, reached out and asked if I wanted to tackle the challenge of making data more understandable to business people together.
Considering the struggles I had faced in the past year, I thought it would be a good change for me. That's how we started the company. All three of us were ready to move on and start a startup.
Another important point that you mentioned is that people often stress about coming up with a good idea before starting a startup. In my experience, you're never really sure about the idea until you try it. The reason I failed in that first year was that I didn't find the right team to tackle the problem, and the team I did find wasn't ready to start a startup yet.
So, in addition to having a good idea, having the right people is surprisingly important for starting a startup. When Correlated came along, I had both the idea and the right people. It was a great combination.
I had previously worked with Tim at Timescale, so I already knew what it was like to work with him. As for John, although we hadn't worked together before, we had a few conversations and I found him to be easy to work with. I felt comfortable with both of them because they had previous startup experience and understood the dynamics of working in a startup environment.
Overall, they seemed easy to work with, so I didn't have to think too hard about it. I already knew Tim, and I didn't see any red flags with John.
On Her Entrepreneurial Attempts
During the year when I was working on different ideas, both HoneClub and InPlaceHealth were actually ideas that I had. I decided to test them out and see what would happen.
With HoneClub, we successfully engaged over 300 people. The idea behind HoneClub was to help those who had lost their jobs during the COVID pandemic transition into a tech career. Since there were many overlapping skills, we would review their resumes, provide a skill profile, suggest suitable job positions, and advise them on resume changes and keywords for better job search success. It was gratifying to see some of the individuals we assisted land the jobs they desired.
However, we eventually stopped working on HoneClub because it became too time-consuming for me and my co-founder. We would work on it until midnight or 1 a.m. every day to manually create these assessments. One day, my co-founder expressed her concerns about the sustainability of this approach, and I agreed with her decision to stop. It made me realize that one crucial aspect to consider when starting a venture is whether you can handle it on a personal level. In the case of HoneClub, the answer was no.
On the other hand, I still believe that InPlaceHealth was a promising project. Many people desire to age in place, and my brother, who conducts aging research, found an assessment to determine someone's health and life expectancy. Our goal was to turn this assessment into a product. However, at that time, I was the only person working full-time on the project. This made it challenging to secure funding, as the healthcare industry and selling to seniors were not popular among investors. It was a valuable learning experience, teaching me not to be overly confident in what I could achieve.
Overall, I believe the Correlated opportunity came at the right moment. It was something I needed at that time.
On Product-Led Revenue
The space of product-led revenue has exploded over the last year. There are numerous terms associated with it, such as product-led sales, product-led revenue, product-led growth, product-led marketing, and product-led everything.
However, the driving force behind this trend is a shift in how people buy and sell software. In the past, when software was installed on servers, the sales process was more focused on enterprise sales. But now, with everything hosted in the cloud, people expect to be able to use a product and determine for themselves whether they want to use it.
Companies can now track how people are using products at a much more detailed level than before. This is the essence of the product-led movement - putting the customer first and recognizing that customers often prefer not to engage in direct communication with companies.
It tries to answer the question: How can you leverage your product to become the driving force behind your go-to-market strategy?
On Correlated's Product Workflow
The way Correlated works is by focusing on helping growth people in growth teams, such as growth PMs or growth marketers. These individuals are responsible for identifying the best people to engage with among all the users of our product. To accomplish this, we collect all available customer data and utilize models to determine the best leads.
We assign scores to these leads to enable prioritization. Additionally, we provide assistance in managing the entire lifecycle, including identifying the best leads, automating processes, nurturing and reaching out to leads, and measuring the conversion of contacted individuals.
In summary, we function as a customer lifecycle management platform for product-led companies.
On Product Integration
It's amusing that you mention this because I believe that integrating with data sources and finding suitable data sources are among the most challenging technical hurdles.
The trend we are following is known as the modern data stack (MDS). This trend relies on the fact that organizations have access to vast amounts of customer data generated by various applications. This data is funneled into a data warehouse to create valuable and insightful models for business intelligence (BI) and correlated tools. This trend guides our priorities when it comes to integrations.
Our data warehouse integration is designed to be self-serve, particularly for data teams. They can easily add different views and columns from Snowflake. Essentially, we have built two separate products within our platform. One caters to growth teams, allowing them to interact with the data, while the other serves data teams, enabling them to connect various integrations using our self-serve data onboarding. At the data layer, we implement various techniques to facilitate a drag-and-drop, no-code interface for growth teams.
On Product-Led Playbooks
The playbooks are incredibly important because one of the main challenges people face is knowing what to do with a dashboard once they have it. Playbooks help guide users on what steps to take after discovering insights from data.
In terms of product-led go-to-market strategy, I believe it is beneficial to break things down into different stages or life cycle stages. To begin, during the onboarding stage, one playbook could be designed specifically for customers with more than 500 employees. In this case, it would be ideal to directly connect these customers with a customer success representative. For smaller customers, automation can be used for the onboarding process, such as sending them a series of emails. This is just one example of how different playbooks can be created for the onboarding stage.
Once a user is onboarded, the focus shifts to activation within the product. Activation refers to users utilizing a few key features and understanding their value. A valuable playbook in this stage would involve targeting users who have not yet activated these features. By sending them campaigns as reminders to come back and activate the features, engagement can be increased.
The next stage is conversion. A useful playbook in this stage, which surprisingly many companies overlook, is to send an email about converting to users who have viewed a gated feature in the product. This is a straightforward tactic that can yield positive results.
Lastly, there is the churn stage. If a user has not logged in for 30 days, it is recommended to send them a reminder and inquire about the reason for their absence. These are just a few examples of playbooks that can be implemented throughout the entire customer life cycle.
In the future, I envision that Correlated will be able to offer pre-built playbooks based on best practices. Currently, users have to create their own playbooks, but as we gather more knowledge about what works best, we can provide guidance on the optimal practices that a product-oriented company should follow. For instance, certain processes like the password reset flow are likely to be standardized across all SaaS companies. Similarly, nurture flows might start looking similar, and conversion points may follow a similar pattern. There is significant potential for us to define these best practices.
On Leveraging Customer Feedback for PQL Scoring
This is actually a really fun one. I think it was a good fit because we actually leveraged customer feedback more often in this case. While people often talk about leveraging customer feedback, it's not always necessary for things like button placement, as common sense can guide those decisions.
However, when it came to PQL scoring, we realized that many customers and prospects were unsure about which playbooks to build and what really mattered. We heard this feedback repeatedly, which led us to start building PQL scoring. We realized that people weren't using our product because they wanted direction on what to do. So, customer feedback from sales calls became our primary source. Sales calls are a great way to gather customer feedback. After that, we had a wealth of recordings that helped us compile an initial list of problems to solve with this product.
Using customer feedback in such cases is crucial because it's a new area. Asking customers what they expect or want can be counterintuitive, as they may ask for something they already know. Instead of focusing on them describing the feature, we concentrate on understanding the problem they are trying to solve, and then figuring out how to help them.
We created various mockups in Figma and gathered feedback on them. Additionally, the PQL score is a machine learning model. We built the model specifically for a few beta customers and had them review the results and the format. Their feedback helped us create the current version, which is still in beta but integrated into the product. While it's not fully optimized yet, it does work. We continue to use this version to gather more feedback.
On The Challenge of Communicating Effectively in Product Management
Upon reflection, I've come to realize that effective communication is probably 80 percent of the job in product management. Throughout my time at Correlated, I have identified four main takeaways.
First, people have difficulty remembering things. To convey information about a feature or tasks that need to be done, it's best to keep things concise. For example, when writing a strategy document or a product overview, I focus on only three main goals, even if I have more in mind. By doing this, I can gauge its effectiveness when an engineer references the goals in a later conversation. If they can recall and connect the feature to a specific goal, it shows that they were actively listening. This highlights the importance of not overwhelming people with information.
Second, listening is crucial. Unfortunately, there are many leaders who do not prioritize listening to others. This is especially detrimental for product managers because they often need to influence and gain agreement from others. To foster investment and collaboration, it's important to actively listen and ask for opinions, even from those who may be quieter.
Another aspect of effective communication, particularly in remote situations, is allowing pauses for people to respond. Research suggests that it can take around seven seconds for someone to process and respond to a question. If you quickly move on after just a couple of seconds of silence when asking if anyone has questions, it's unlikely that anyone will actually ask. Thus, it's crucial to allow sufficient time for responses.
Lastly, it can be frustrating when you provide a product specification and no one seems to remember its contents. Consequently, you find yourself repeating the information multiple times. While this can be exasperating, it's important to accept that repetition is often necessary. Keep repeating the information until people start echoing it back to you.
These are the four key lessons I have learned so far regarding effective communication in product management.
On Learnings on Customer Discovery at Early-Stage Startups
When conducting customer discovery, it is important to ask open-ended questions. The format I usually suggest for customer discovery is as follows: in a 30-minute session (which is typically the longest amount of time available), the first 10 minutes should be dedicated to asking open-ended questions about general problems and top priorities. This is where you explore different perspectives. The remaining 20 minutes should be focused on discussing what the customer is currently doing. This is why I believe customer discovery can also be done during sales calls, where you have the opportunity to pitch your solution.
In the early stages, it is important to talk to people who align with your target audience. For example, if you are targeting growth, talk to individuals who specialize in growth. You don't necessarily need to talk to a hundred of them. In my experience, after speaking with around 20 people, they tend to express similar opinions. Startups don't have the luxury of time to talk to thousands of people, so I disagree with the notion that you need to reach such a high number. Once you start noticing a trend, focus your efforts there and avoid wasting time.
On Early Signs of Product-Market Fit
I have been contemplating this problem extensively because when I consider Cockroach and Timescale, I feel like they were much further along in terms of product-market fit than Correlated was. By the time I joined Cockroach and Timescale, the product was already established, so I just had to figure out how to sell it and focus more on market fit rather than product fit. But with Correlated, everything started from scratch. So, I had to learn about everything all at once, making it challenging to determine what influences what. It was definitely a different experience.
Overall, I believe that achieving product-market fit is evident when you observe an increase in adoption speed. This can manifest as gaining more users and generating more revenue. However, I personally don't find this definition of product-market fit particularly useful for early-stage startups.
Instead, I prefer to look for early signs of product-market fit. As we discussed earlier, body language is crucial. If you show someone your product and their reaction is, "Wow, this is great! I would definitely use it," that emotional response is a positive early indication.
Another important factor is whether users return to use your product frequently. Do you solve a problem that they constantly worry about? Otherwise, you might only be addressing one problem for them, such as building a scoring model, but they may never want to use it again. Therefore, it is essential to ensure that the problem you are solving is recurring and significant.
Another good sign is when your customers are satisfied and refer you to others. This indicates that, at least for that particular customer, you have achieved product-market fit.
Moreover, even though we are discussing these early signs, it is crucial to see repeatability in the go-to-market process. For example, if a customer refers you, and then you approach another customer with the exact same profile, do they also have an emotional reaction and consider you important? Do they also refer you? Being able to repeat this go-to-market process is equally important.
Timestamps
(01:41) Diana shared her upbringing in Orlando and her undergraduate experience studying Economics at MIT.
(03:27) Diana reflected on valuable lessons from her internships during college.
(05:58) Diana brought up her learning during the year working as an investment banking analyst in the technology group at Morgan Stanley.
(09:10) Diana recalled her transition from investment banking into venture capital at Norwest Venture Partners.
(11:52) Diana discussed the takeaways from her time as a venture associate meeting entrepreneurs on a regular cadence.
(14:23) Diana recalled her decision to leave venture capital and become the first hire at the product organization at Cockroach Labs.
(19:00) Diana went over the challenges and learning curves as a non-technical first product hire at Cockroach.
(21:26) Diana extrapolated on the idea of determining the best-fit product strategy rather than blindly following frameworks.
(23:55) Diana described her experience as the first hire into the product organization at TimescaleDB.
(26:40) Diana highlighted the challenges of open-source GTM.
(27:56) Diana reflected on her 3-part blog series on building a product for the most dissatisfied customers first, the majority next, and the full need in the long run.
(30:40) Diana shared 2 tactical lessons to cultivate focus as a product manager.
(32:44) Diana share the founding story of Correlated alongside her co-founders, Tim Geisenheimer and John Pena.
(35:38) Diana briefly touched on her 2 entrepreneurial attempts during COVID-19.
(38:30) Diana unpacked the notion of Product-Led Revenue and described how Correlated works at a high level.
(40:49) Diana highlighted the role of integrations within Correlated's product strategy.
(43:04) Diana mentioned Correlated's product-led playbooks to help users manage their product-led strategy from start to finish.
(45:40) Diana explained how she leveraged customer feedback to ship the feature called PQL Scoring that leverages machine learning to identify the best leads.
(48:51) Diana shared the consistent principles that have remained the same for successful communication in Product Management.
(52:30) Diana discussed her learnings on customer discovery at early-stage startups.
(56:08) Diana reflected on the early signs of product-market fit that carry through all of her startups.
(58:58) Conclusion
Diana's Contact Info
Correlated's Resources
Correlated Launches to Bring Product-Led Revenue to Market with $8.3M in Funding
Correlated launches PQL Scoring to accelerate your product-led strategy
Mentioned Content
Blog Posts
"The Standard Due Diligence Process" (Jan 2016)
"Mistakes to Avoid when Pitching to a VC" (Jan 2016)
"My Startup Litmus Test" (Feb 2016)
"Why I left VC to join Cockroach Labs" (April 2017)
"My First 90 Days as the First Product Hire" (May 2017)
"Coding != Technical: What It Means to be Technical as a PM" (Aug 2017)
"How learning to sell makes for a better product manager" (Nov 2017)
"Roadmap Planning: Users First, Features Second" (March 2018)
"Build something people will use more than once" (May 2019)
"Focus on the unhappiest, most dissatisfied customers first" (May 2019)
"Build for the majority" (May 2019)
"Why user interviews can fail you when starting a startup" (Sep 2021)
"Tackling the challenges of communicating effectively in product management" (Jan 2022)
"Some Learnings on Customer Discovery at Early-Stage Startups" (May 2022)
"4 early signs of product-market fit" (Sep 2022)
"Give customers what they want, but not what they ask for" (Sep 2022)
People
Book
"Crossing The Chasm" (by Geoffrey Moore)
About the show
Datacast features long-form, in-depth conversations with practitioners and researchers in the data community to walk through their professional journeys and unpack the lessons learned along the way. I invite guests coming from a wide range of career paths — from scientists and analysts to founders and investors — to analyze the case for using data in the real world and extract their mental models (“the WHY and the HOW”) behind their pursuits. Hopefully, these conversations can serve as valuable tools for early-stage data professionals as they navigate their own careers in the exciting data universe.
Datacast is produced and edited by James Le. For inquiries about sponsoring the podcast, email khanhle.1013@gmail.com.
Subscribe by searching for Datacast wherever you get podcasts, or click one of the links below:
If you’re new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.
