[PM Talks] The Journey from Idea to Launch: A Deep Dive into the Lifecycle of SaaS Products

How do you get from an initial idea to a successful product launch and sustainable business? That’s a mystery explained in many product management books, and a topic many product leaders think about day and night. 

In our latest PM talk, we interviewed Chad Thomas, the Principal Product Manager at Aiwyn. Chad gets straight to the point, sharing his experiences as well as ideas and frameworks from other famous product thinkers.

What’s the journey from an idea to a product launch? How do you know when to stay true to your original vision versus adapting to customer feedback? How do you ensure your developers are on board when they have their own opinions about how features should be built? And when it’s time to launch, what strategies help make sure the new release will resonate with early users and drive success?

Get the answers in this podcast episode!

‍

About Chad Thomas:

• Principal Product Manager at Aiwyn
• Interdisciplinary background in chemical, mechanical and civil engineering
• Follow Chad Thomas on Linkedin

Could you walk us through the journey from the initial idea to the launch of a SaaS product?

I'd like to take a step back and talk about something I've worked with called the Double Diamond Framework. Many product managers are probably familiar with it. If you're not, it’s essentially a way to define the problem and solution spaces in a very structured manner. It begins with discovery and defining the problem you're trying to solve—this includes identifying the pain points your customers are experiencing. However, it doesn’t always have to be a pain; it can also be an opportunity to innovate or deliver significant value to customers.

In this first phase, you're focusing on divergent thinking, gathering insights by talking to customers, capturing ideas, and understanding what's keeping them up at night or causing them issues day-to-day. Sometimes, it's even about helping them foresee challenges they might not currently anticipate. Then, you move into convergent thinking in this first diamond, where you start narrowing down those ideas. Here, you're deciding which specific problem or opportunity to address. This could apply not only to a new product but even to a single feature or an improvement to an existing product.

The second diamond in the Double Diamond Framework is the design and delivery phase. This is where you're creating prototypes, gathering feedback from customers, and ensuring that you’re solving the right problem. You validate that what you're building will truly provide the value customers need. Then, you move into the delivery phase, where you finalize the requirements, establish the acceptance criteria, pass it to the development team, and deliver on what you’ve committed to build.

Throughout this process, it's not just the product managers involved. Some people say product managers are the "CEOs of the product," but I don’t subscribe to that. I believe in a three-way ownership of the product between the product manager, design lead, and tech lead. Each has distinct responsibilities: the product manager focuses on business viability and customer value—ensuring it’s financially feasible for the business, aligns with business vision, and provides enough value that customers are willing to pay for it. After all, without revenue, even the best solutions won’t survive, and that’s not beneficial for anyone.

The design lead ensures usability for the customer. If only the product manager and engineer are involved, there’s a risk of over-engineering, so it’s crucial to have a strong design lead guiding this part of the process. The tech lead ensures that what we’re building is feasible. With new AI functionalities, for example, while there are incredible applications, it’s essential to confirm we can build what we’re promising.

Maintaining strong collaboration between these three roles throughout discovery, definition, design, and delivery phases is vital. And once the product is complete and ready to launch, we need to have a well-defined product launch strategy. This includes organizing webinars, demos, attending industry events, and leveraging PR to reach both existing customers and the broader market. For new products without an existing customer base, it’s even more important to execute an effective launch strategy.

After launch, the process doesn’t end; it becomes a feedback loop. You can think of this entire process as a flywheel. Once we've gone from idea to product, we should continuously iterate, identifying new problems the product can address. This not only deepens customer value but also leads to better business outcomes.

In many startups, the CEO initially handles product management. When you joined, were you taking over this role from the CEO? What challenges did you face, and can you share any experiences from that transition?

So, obviously, what I was referring to earlier involved a robust product team. But let’s take it back to a situation where it’s just a founder and perhaps a technical founder. In that case, you’d have your market-facing person and your more technical, in-the-business person—maybe that’s your technical CTO.

Now, that doesn’t change the fact that you still need the roles of product manager, designer, and tech lead in the process. The elements I mentioned earlier—viability, value, usability, and feasibility—all still need to be addressed, even if those responsibilities fall on just a CEO and a CTO. I wanted to clarify that before going deeper.

My first experience in product management actually illustrates this. I come from an engineering background and started my career building automated control systems in the pharmaceutical industry, which was exciting and gave me a solid foundation in systems thinking. Then, I was exposed to the accounting industry through my wife, who’s a CPA. She worked with a practice management solution that had just been acquired by a successful CEO named Carl Coe.

Carl was fantastic to work with; he quickly realized that this business he had acquired was sort of on autopilot. It had a strong customer base with very satisfied clients, but it was a legacy product with nothing modern—no cloud-based applications, for instance. Customers were eager for that next phase of innovation.

Recognizing his own limitations, Carl, whose strength lay in acquiring, growing, and eventually selling businesses, saw that he needed a product expert to lead that aspect of the business. So, he brought me in to help launch the product management function from the ground up. Before that, there was no real focus on product; the attention was mostly on the technology and the market-facing side. It was a fantastic opportunity for me to implement a structured approach with discovery, definition, design, and delivery—or develop, depending on which version of the framework you prefer.

Stepping into that role required a strong personality. You need to be willing to push back on the CEO when necessary, standing by your insights—ideally backed by data or at least solid hypotheses. This startup scenario often lacks a focused product function, or the CEO essentially fills that role.

In another experience, I worked with a CEO who was very much a product person. He had a clear vision, and understandably, there was some initial resistance to hand over any control or trust someone else to guide what he had built over five years.

That brings its own set of challenges. Instead of coming in to immediately build product processes, you first need to establish trust with that product-focused founder. They need to see you as a partner in driving their vision forward. So, in that kind of setup with a CEO and CTO, you’re either dealing with a market-focused CEO, which has one set of challenges, or a product-focused CEO, which has another.

I’ve navigated both scenarios in my career.

If I have an idea for a new product or an improvement to an existing one, how can I validate whether it brings real value to customers? Are there specific frameworks you recommend for this validation process, and could you share some examples of how you've used them?

The first thing I’d recommend to any listeners is to check out Teresa Torres’s book, Continuous Discovery Habits. It’s fantastic for not only validating what you’re building but also for continuously generating new ideas to validate. This approach combines both functions in a single process, making it a powerful tool in my toolkit. It all starts with the customer—lots of interviews, lots of surveys. I make it a point to have customer calls for at least a couple of hours each week. It’s a big investment, but it also yields a tremendous ROI. Not only does it help generate new ideas, which are essential to validate, but it also provides an opportunity to refine those ideas with customer input.

We start by saying, “This is the problem you’re facing. Let’s validate that it’s actually valuable to solve before jumping to solutions.” This validation step is all about customer conversations, a really effective tool in this process. Once we have some interviews and a clearer understanding of their problems, rapid prototyping with tools like Figma is incredibly valuable. Non-technical customers can find it challenging to talk about features in an abstract way, which often leads to vague requests like, “I’d love it if it did this or that.” Prototypes allow us to focus discussions by showing clickable versions of possible solutions.

Typically, I’ll bring two or three solution variations in a low-fidelity prototype format. This way, we’re not caught up on button positions, colors, or specific details, but rather on the overall direction. Prototypes should be shared with customers and prospects as early and often as possible.

Another effective approach is experimenting within the market. For instance, during product launches or events, you can test interest in new ideas with soft or “dark” launches. By introducing an idea and gauging interest—say, through waitlists or in-person conversations at events—you can measure initial traction. In existing products, adding a “coming soon” feature button that doesn’t yet go anywhere allows you to track interest through product analytics tools like Pendo. This can reveal which customers are drawn to the new feature and how they engage with it, providing early feedback on potential value.

Competitors also offer valuable insights. While you don’t want to engage in a “feature war,” listening to customer feedback on competitors’ offerings can highlight underlying needs. This can inspire you to build better solutions, not necessarily by copying features but by understanding the problems they address. As I like to say—I can’t remember where I first heard this—I’m competitor-inspired, but not competitor-obsessed. I don’t obsess over what they’re building, but I can certainly draw inspiration.

If you’re looking for a specific framework, the lean startup approach is great for rapid prototyping and getting ideas in front of users quickly. While I don’t fully embrace the “move fast and break things” mentality, especially in accounting, where mistakes can have severe consequences, I do support putting prototypes out there and welcoming feedback. Don’t be afraid of negative feedback; let customers know these are just ideas you’re working on, and they’ll appreciate being part of the process. So let your customers guide you whenever you’re ready.

You mentioned spending a lot of time on calls with customers—what percentage of your time do you allocate to that? Additionally, what’s the ratio between customer feedback gathered from these calls versus the insights you gain directly from product data, such as tracking usability when launching a new feature?

I’d say I spend about 10 percent of my week on customer calls. So, if I’m working a 40-hour week, that’s about four hours spent on customer calls. It’s not a small amount of time—it’s a solid portion of my calendar. But again, the ROI on that 10 percent is tremendous. You gain a wealth of insights from these interactions, helping you understand what to build next, where customers find value, and where they may feel the current solution is lacking. I can’t overstate the importance of those customer interviews and discovery sessions.

Now, there’s a distinct difference between the customer feedback we gather during discovery and the product telemetry data we collect through platforms like Pendo. They serve different purposes, and I’ll explain. 

During discovery, I’m gathering ideas for features or products that haven’t been built yet. Since you obviously can’t track what doesn’t exist, discovery is all about listening to the customer’s needs and identifying areas where we can add value. This approach centers on problem-solution fit—confirming that the problems we’re solving are genuinely valuable for the customer.

On the other hand, once something is built, I rely on usage metrics from tools like Pendo to understand how customers are engaging with it day-to-day. I’m looking at user flows, any points of frustration in the user experience, and time-to-value—whether they’re able to complete those key activities that drive real benefit from the application. This data is also useful for identifying areas where we could improve the user experience.

Sometimes, you might see customers using the product in ways you didn’t anticipate, which can be a strong signal that there’s an opportunity for a purpose-built feature. Observing this allows us to consider new ideas for what to build next, often without needing additional discovery sessions with customers.

As a product leader (or CEO) with a clear vision for your SaaS product, how do you balance your long-term goals with the customer feedback you receive, especially when users are asking for specific features? How do you decide when to stay true to your original vision versus adapting to customer requests?

Yeah, finding that balance can be tough because sometimes our vision of the world is fundamentally different from what customers are currently doing. 

Often, when customers request features, they’re really just aligning with their existing processes. In these cases, it’s essential to go back to the basics and talk honestly with the customer. Ask them, “What problem are you trying to solve with this feature?” You might find that you don’t need to deliver exactly what they’re asking for; it could be something slightly different that better aligns with your product vision. 

Of course, sometimes what they’re asking for fits perfectly with your vision, especially if it’s a key feature that aligns with a minimum viable product (MVP). Prioritizing those "threshold" features is necessary to make sure your app is competitive in its category.

However, I’m a strong advocate against getting into a feature war or falling into what Melissa Perri calls the “build trap,” where you simply churn out whatever customers request, essentially becoming an outsourced development shop. It’s crucial to keep your vision in mind. 

That said, it’s also valuable to maintain a flexible approach to how you achieve that vision. One of the biggest challenges I see in these situations is when “visions” aren’t truly visions—they’re more like a predefined list of features that a CEO or leader decided should be built. But a true vision is about a future state and how things could be, with a range of potential features and capabilities to achieve it.

Having a clear, well-defined vision makes the whole process smoother. And ultimately, it always comes back to the customer. When you’re out in the market, you might find that your initial vision doesn’t fully align with what customers need, and that’s okay. You’re allowed to pivot and adjust your perspective.

The key is not to take customer requests at face value. For certain features, it may be obvious that it’s a no-brainer to build them, but for most feature requests, dig deeper. Always ask why they want it. What problem are they trying to solve? Are there alternative ways to meet their needs without building exactly what they’re asking for? This is the process I follow, focusing on understanding the core need behind the request.

Do you actively share your product vision with customers during your calls to get their feedback and gauge their excitement about upcoming features? How important do you think it is to communicate the future direction of your product, rather than just building features without customer involvement?

When a customer buys your product, they’re not just buying the product itself; they’re buying into your vision, the community around your product, and the talent behind your team. It’s far more than just an application category or a feature set—they’re investing in the direction your business is heading. Without visibility into that direction, customers can’t effectively build their own tech stack around it. They need to understand your aspirations from a product perspective to plan their technology strategy for the coming years.

Communicating that vision is crucial—not only to validate it and generate excitement but also on a tactical level. It’s important for customers to know where you’re going, both in terms of vision and roadmap. For example, we use Jira Product Discovery for road mapping, presenting customers with a “now, next, later” view. These aren’t fixed timelines or set-in-stone commitments; we avoid specific dates to retain flexibility. This way, we’re able to adapt rapidly to shifts in the industry, such as the surge in AI adoption.

The speed at which LLMs have been adopted is a perfect example. If we had committed to a rigid two-year roadmap, we’d be in handcuffs, unable to pivot and invest in these emerging technologies. Instead, we stay honest and transparent with customers: “This is our vision; this is where we want to go together with your input.” By framing it this way, we open up a conversation that fosters trust between the customer and the business.

Ultimately, it all comes back to being genuinely customer-obsessed. By focusing on the customer, we learn not just about the features they want but, more importantly, about the problems and opportunities they face—problems we can help solve as a business.

Can you share some of the toughest decisions you've faced about including or excluding certain features? Have there been instances where a client chose to leave because you didn't build a feature they wanted or approached it differently?

We had a top 30 firm as a customer requesting us to build functionality that no other customers would use—it was essentially a custom feature just for them. So, we had to sit down and assess the ARR potential from this firm. If a customer is willing to pay six or seven figures, depending on the size of your business, it may make sense to say, “We’re not a custom dev shop, but we’ll build this.” This approach can provide cash flow that allows us to better serve the rest of our customer base and attract further investment.

It’s perfectly okay to say, “Normally, we don’t operate this way, but this makes sense for us right now.” However, it can be a bigger issue if this request is coming from sales with a prospect saying, “I can’t buy your product without this specific feature.” Similarly, customer success may bring feedback from an existing customer who needs a feature to avoid churning.

In both cases, you need to treat these requests as ideas, similar to those gathered during the discovery process, even though they come from different sources. Whether from a prospect in sales or a customer in CS, these requests still feed into the idea engine.

Evaluate them like any other idea: What’s the ARR potential? Is there churn risk? Does it add value to the wider customer base? What’s the reach? The RICE scoring model—reach, impact, confidence, and effort—can be useful for this kind of assessment. I like to stay pragmatic and not overly rigid with frameworks, but it’s helpful to turn back to stakeholders and say, “This may bring us revenue, but it’s complex to build, and no one else will use it.” In such cases, it doesn’t make sense to proceed.

On the other hand, if a request is straightforward, like an API extension to allow better integration, and aligns with significant revenue potential, it may be worth pursuing. In our case, this firm wanted more APIs to integrate our solution into their ecosystem, consuming our functionality through another interface. We found that with minor adjustments to our APIs and some iframe optimization, we could meet their needs with minimal effort.

This was beneficial for us because, from a product marketing perspective, having their logo was valuable, and it brought in considerable revenue. It’s always about being pragmatic—you can’t ignore these edge cases where building something custom might make sense for the business.

Moving into the development phase, once a feature is defined, what challenges do you face with your dev team? For example, how do you handle situations where developers suggest building something in-house instead of using existing solutions?

I’d say there are four common challenges I encounter. The first is scope creep. This happens when the agreed-upon scope gradually expands beyond the original plan. That’s a big challenge from a resourcing perspective; suddenly, you don’t have enough people to build what was initially promised, which impacts timelines. But it’s also hard on team morale—they start to feel like they’re just a feature factory. It’s demoralizing if everyone’s excited about building one thing, and then it keeps changing with additions here and there.

To address this, clear documentation is crucial. Working closely with the tech lead, design lead, and product manager, we create a detailed spec of what we’re building before starting. It’s also essential to have a change control process in place to communicate why any scope change is happening, and to highlight potential timeline impacts. Personally, I don’t like asking people to work weekends, so I’m always clear about how changes might affect deadlines.

The second challenge is technical obstacles. Sometimes there’s something in your architecture that complicates what you’re trying to deliver, or a tech vendor doesn’t work out as expected. With new technologies, especially AI, unforeseen challenges can arise. To manage this, it’s helpful to have a risk management plan in place and maintain transparent communication with the tech team. I’m a big fan of technical spikes, which allow teams time to explore and address technical issues before they become problems, rather than just piling on more stories without a chance to step back and validate the technology.

The third challenge is resource limitations. Often, product managers plan an idea with the business, only to discover that the necessary resources or budget aren’t available. This can turn into a timeline issue if you have limited staff, but it can also be a budget issue if there isn’t enough to buy third-party products or partner integrations. Sometimes, limitations arise from technical constraints like performance issues or the lack of an expected API. All of these resource constraints can create obstacles during development.

The fourth challenge is miscommunication. Sometimes there’s a misunderstanding about what’s being built, and the final product doesn’t align with expectations. To avoid this, it’s critical to ensure the development team understands not only what they’re building but why. Show them the vision, the value, and clickable prototypes to give them a sense of how their work fits into the broader picture. Once development starts, keep the communication channels open through standups, sprint rituals, retros, and planning meetings. This allows the team to raise any issues or questions as they come up.

Those are probably the four main challenges I encounter in the development phase.

Once a feature is ready for launch, how do you plan major product releases to ensure they resonate with users? What strategies do you use for a successful launch, and what key lessons have you learned from past launches—both successes and failures?

It all comes back to communication with stakeholders outside the product team—customer-facing teams, internal stakeholders, and customers themselves. If you don’t communicate what you’ve built, its value, and how it works, you’re setting yourself up for failure. You’ll end up with new functionality in the application, but no one will know how to use it or that it’s even there. Customer teams will be caught off guard, which I’ve seen happen in several roles. Keeping everyone aligned on a new product launch is crucial but can be challenging.

To build a solid launch plan, the first step is alignment. Setting clear objectives is essential—defining what success looks like for this launch. Are we aiming for new users, increased engagement, or another KPI? Setting this “North Star” helps keep everyone focused.

The next step is identifying and understanding your audience. We work with both smaller and larger firms, so the messaging and language need to be tailored to each group. 

After that, defining the channel strategy is key. Are we using email marketing, social media, industry events, blog posts, or webinars? Clearly defining the channels and activities and ensuring alignment across the business is critical.

Communication is absolutely the top priority. Marketing needs to align their messaging with the value we’re delivering, sales should have the materials and training they need to discuss and demo the product, and customer support must understand the product so they can answer questions effectively. Each customer-facing team has unique needs, and it’s the product team’s responsibility to ensure they’re prepared.

Once alignment is established, we enter the pre-launch phase. This often involves a beta program with existing customers. By launching the product to a small group of beta users, we can confirm it works as expected, gather feedback, and build advocacy. We also collect reviews, testimonials, and case studies during this phase, which can be invaluable for the full launch.

In this stage, content creation is crucial. This includes user guides, tutorials, FAQs, and other resources to facilitate onboarding. Marketing and product marketing teams, along with any training teams, contribute to this content to ensure everything is ready for users. Additionally, creating pre-launch buzz—through teasers, press releases, or paid partnerships—is beneficial, especially in fields like accounting, where associations can amplify reach.

Then comes the full launch. You might choose a staggered rollout, releasing to different cohorts in stages to manage risk. For instance, if you have a particularly challenging customer relationship, it may not be wise to introduce a new product to them first. However, be mindful not to drag the rollout indefinitely; it’s essential to have clear timelines.

After the launch, monitor usage through tools like Pendo, Google Analytics, or any platform that provides product telemetry. Track engagement to confirm users are adopting the product as intended and deriving value from it. This step keeps the feedback loop active, as we’re continually pushing value to customers and need to ensure they’re using it effectively.

Ultimately, product launch is an ongoing cycle, much like a flywheel. By continuously monitoring how customers use your application, you’ll capture valuable insights to inform future improvements and maintain momentum in delivering value.

Let's get to our favorite fives: questions we ask every product manager who joins us on this podcast. First, what is your biggest challenge as a product manager?

I’d say the biggest challenge is communication with customer-facing teams during new product launches. 

Going back to our last discussion, alignment is key—making sure everyone understands what’s being built and why, and ensuring they have the resources to do their jobs effectively.

I break this down by team—sales, support, customer success, and marketing. If these teams aren’t fully empowered, the product organization will struggle to achieve the adoption goals. Providing them with the tools they need to reach new customers and help users adopt the product is crucial. This is particularly challenging because you’re working with various stakeholders, each with unique needs.

The solution we’re always working on is keeping communication lines open. It’s essential to be receptive to feedback so that teams can share openly and honestly about what’s working and what isn’t. When someone says, “I’d love it if you could provide X, Y, or Z,” being responsive as a product person makes all the difference.

If you could choose one key metric, your North Star, to define your success as a product leader, what would that be?

I’d say user adoption and customer engagement with key features are the most critical metrics. At the end of the day, we want to build a product that’s viable for the business and valuable for the customer. If we’ve built it, we know it’s viable; the focus then shifts to ensuring it’s valuable. The only way to confirm its value is by seeing customers actively using it and extracting that value.

This engagement doesn’t need to follow a daily active users model like Facebook, especially since one of our products is highly seasonal. So, rather than tracking daily usage, it’s about ensuring that customers are achieving their goals with the product. For example, if they need to send out 80,000 engagement letters, we want to see that they’re sending those letters and that they’re getting signed promptly. Similarly, if they need to request documents from clients, we need to see that documents are being requested and uploaded by clients.

Ultimately, the specific metrics vary based on the product’s use case, but it all comes down to customer engagement and whether they’re reaching the outcomes they intended when they purchased the product.

How do you collect feedback from your customers? What processes or tools do you use?

I prioritize constant communication with customer success managers (CSMs) and account managers because they’re an invaluable source of feedback. They often receive insights directly from the business side of our customers, which gives me a higher-level view of how we’re impacting them. While I often get feedback from end users, CSMs can provide perspective on the broader customer experience, so building a strong relationship with them is a key part of my feedback process.

Another essential tool is customer advisory boards or focus groups, which help us conduct continuous discovery on both new and existing products. These structured feedback sessions are vital for refining and enhancing our offerings.

Product telemetry tools are also critical, as they provide detailed insights into user flows and engagement patterns. 

And finally, an often underrated tool is the classic survey. In-app surveys, in particular, are powerful because they capture feedback in real time, within the context of the user’s experience. This is far more effective than email surveys, which lack the immediate context of application use. I’m a big fan of in-app feedback as it allows us to capture authentic, situational responses.

When it comes to 'build versus buy', how do you decide?

That's a great question, and it’s always a challenging decision. There are plenty of effective point solutions available that tackle specific functionalities, so the first thing we consider is strategic importance. We ask ourselves if building this feature would create a competitive differentiator or “moat” for us. Would it prevent others from simply working with the same vendor and replicating our functionality?

Another factor is time constraints. If there’s a specific timeline to hit, we have to evaluate whether we can realistically build the solution within that timeframe. If not, a buy decision might make more sense. 

Resource limitations also come into play. For instance, if we don’t have the necessary team or skill set—like for building an Intelligent Document Processing (IDP) platform—it could be more feasible to buy rather than build.

Cost analysis is another essential consideration. Even if we have time and resources, we need to weigh the cost of building against licensing from a third party. Building involves both an initial development investment and a long-term commitment to maintenance and scalability, including the need to support future enhancements. With a buy scenario, you rely on an external partner whose sole focus is developing and maintaining that tool, which can alleviate some of the long-term maintenance burden.

Compliance is also critical, especially when handling sensitive information like PII. In some cases, working with third-party vendors might pose compliance challenges, making an internal build more favorable.

Lastly, integration capabilities are key. If a potential partner offers strong APIs and seamless integration, that can significantly accelerate time to value. But if no suitable partner offers a robust, easily integrated product, then building might be the better path.

So, we consider strategic importance, time and resource constraints, cost analysis, compliance, and integration capabilities to find the best path forward.

What role do integrations with third-party products play in your product?

Integrations are of tremendous importance for us. Many of our clients use a mix of legacy tax and audit applications alongside more modern ERP systems, with a lot of valuable data locked within these tools. 

Since Aiwyn is a practice management and client portal solution, we need that data in our application to drive behaviors and insights. While we’re not looking to build an audit platform ourselves, having integrations is crucial to achieving our vision of highly automated practices. By pulling data from these systems into Aiwyn, we enable users to leverage it within the context of practice management.

Additionally, in many firms, different departments operate almost as separate entities, with their own tech stacks in tax, audit, and advisory services. It can be highly strategic to integrate with these existing applications rather than trying to replace them, especially when a tool is deeply embedded in a department’s workflow. For example, to create a unified client experience, we might integrate with a third-party tool to show requests from that system within our client portal.

CRM integrations are also highly valuable. Having full visibility into the client relationship is essential in practice management, and we’re not aiming to replicate tools like HubSpot or Salesforce, so it makes sense to pull in that data as well.

I tend to categorize our integrations into three main areas:

1. Core applications (ERP, tax, audit platforms) that house essential data.
2. CRM systems, which provide a complete view of client relationships.
3. Best-of-breed point solutions specific to departments, which enhance the functionality without replacing existing, deeply embedded tools.

These are the three main categories that guide our integration strategy.

Closing remarks

We spent nearly an hour with Chad and learned so much—from the importance of regularly talking to customers about the problems they face and the opportunities these problems bring, to the team alignment and talent needed to successfully move from idea to launch.

You can contribute to the topics we prepare for our PM talks. Post your desired question or topic below, and we’ll happily consider it for future episodes!

You’ve just read an interview from our podcast, where we speak with product leaders who share their experiences. Follow us on Spotify or YouTube for more episodes.