Carta

Ideas for new features come from various sources, including customer feedback, market research, internal brainstorming sessions, competitor analysis, and emerging technologies. To decide which ideas to invest in, product teams evaluate them against business goals, user impact, and technical feasibility. Personally, I find a lot of joy during the ideation phase. The biggest challenge I see teams face is bringing these ideas together into a cohesive narrative that generates virality before the product is even built.

My two go-to frameworks are MoSCoW and RICE. The first focuses more on prioritization based on the importance of features, while the latter emphasizes prioritization based on the Reach, Impact, Confidence, and Effort involved in each option. In your specific situation, I'd start by outlining a list of user stories and then using one of the frameworks above to compare build vs. buy solutions.

At Carta, our product teams collaborate closely with product marketing when building the roadmap to offer context into upcoming features and product enhancements. Product marketing leverages this information to develop compelling messaging, positioning, and go-to-market strategies aligned with the product roadmap. Once we get close to an upcoming release, we usually work together more often to shape the value proposition and share it with customers and prospects via webinars, blogs, and updates to our website.

Navigating a product pivot involves recalibrating communication with stakeholders, including customers, investors, and internal teams. The primary goal is to build trust. I recommend transparently communicating the rationale behind the pivot and framing it as an opportunity for innovation and growth. At this phase, shifting your team's focus from long-term planning to short-term goals is crucial. Your ability to demonstrate tangible progress toward these short-term goals will deepen trust and reinforce confidence in the new direction. Finally, I'd recommend maintaining an "adaptability mindset" and iterating on the roadmap as you discover new insights. Good luck!

I usually focus on deeply understanding the "why" behind an ask or input. One time, I heard "We should build a new product A" directly from a CEO. Asking the question "why" helped me understand that the broader delivery organization was undergoing a transformation, and building a new product would support the business while creating customer delight. In return, when conveying a point of view, I often refer to data or customer anecdotes. Offering customer-centric insights helps executives understand how our product shapes customer behavior, while data brings clarity to how it impacts larger business objectives.

Your key stakeholders to shape a roadmap are: 1. Customers/Users: Capture direct feedback and use data to gain insights into user needs, pain points, and feature requests. 2. Sales & Marketing: This group will provide insights on market demand, competitive landscape, and feedback from prospects and customers. 3. Support & Customer Success: These teams are an excellent source for understanding common issues, pain points, and feature requests from existing customers. 4. Executive team: Seek guidance from the executive team to refine product strategy and align on business objectives. 5. Your product team: depending on the interconnectedness of your product strategy with other products, you will often need to align your team's roadmap with upstream and downstream dependencies with other teams in your organization. 6. Your core team: typically, UX, EM, and the engineering team will provide input on technical feasibility, resource constraints, and UX decisions that will influence a delivery timeline for new features. How to balance influence vs control: 1. Ensure there is regular communication with the stakeholders that sets clear expectations. For example, sharing the roadmap with any of the groups above enables your stakeholders to provide input and be heard. 2. Use a prioritization framework such as MoSCoW or RICE to objectively evaluate features and weight their impact against technical feasibility. 3. Embrace regular feedback loops and take an iterative approach to deliver MVPs, validate assumptions, gather user insights, and refine features based on real-world usage and feedback.

Let me begin by emphasizing the problem. It's important to prioritize sales yet balance growth with sustainable practices that prioritize customer satisfaction and ongoing innovation within your product teams. How to gain autonomy in shaping your roadmap heavily depends on your organization's culture. Understanding whether sales, product, or engineering primarily influences the company's direction is key. In a product-driven culture, for instance, your product leadership (CPO) can often support your decisions, provided you equip them with data, customer insights, and other relevant information to justify prioritization choices over sales-driven initiatives. It's also a good idea to invest in strong relationships with Sales leaders who often influence your roadmap. By helping them grasp your product strategy, resource limitations, and overarching goals, you can bridge the gap between solving individual customers' needs vs. building a scalable product. In other words, you must align your x-organization stakeholders on a balance between short-term sales objectives with long-term product strategy.

At Carta, our end-to-end process for prioritizing features is rooted in strategic alignment, user-centricity, collaboration, and data-driven decision-making. For simplicity, you can think of the process in the following way: 1. Align: Our process begins by aligning the team's product strategy with the overarching business objectives, ensuring that every feature we prioritize contributes directly to the company's strategic goals. During this process, we gather valuable insights from various sources, including user feedback and thorough market analysis. 2. Refine: Once we clearly understand the landscape, product owners will lead the process of drafting PRDs. These documents outline key feature ideas and establish measurable metrics that will define the success of each proposed feature. By defining success metrics upfront, we ensure that every feature aligns with our KPIs and contributes to our overall success. 3. Collaborate: Collaboration is key in our process. PMs will partner closely with engineering and UX counterparts to assess each feature's feasibility and size the investments needed to bring these features to life. We leverage frameworks like MoSCoW or RICE to normalize the value of each feature against its associated costs. From here, we'll generate a final roadmap to guide our internal teams and inform our customers about what's coming.

Build vs buy is a common PM dilemma. As for my own challenges, a couple of examples come to mind: 1. Support & reliability - at Carta, we use Mandrill as our email service provider (ESP). The service was brought in a long time ago and, over the years, became an unsupported offering from Mailchimp. Problems included downtime, unresponsive support, and no major product updates. When we started to evaluate alternatives, we realized that the cost of change was too high, so we decided to add layers of fallback, such as an internal queue. This way, even if the service is down, we queue emails internally and resend them when the third-party service gets back online. 2. Cost - AWS & Circle CI cost was fine for us in 2020, but during the economic downturn, companies, including ours, started focusing on spend. Commonly, the cost of cloud infrastructure is some of the highest expenses after headcount, so our engineering teams naturally started to focus on optimizing the efficiency of our deployments, CI pipeline, etc. 3. Extendibility - Readme & OpenAI are the latest services we've used that offer great baseline functionality, but then we quickly ran into limitations with customization and developer community support (Readme) or rate limits and latency (OpenAI). Often, teams can engineer solutions that remedy the lack of desired functionality; however, staying on top of this with a CSM informed a better decision-making. IMO, procuring a new service is like bringing a new member on your team - they could be a huge multiplier or a detractor. Don't take shortcuts studying the candidates and doing reference checks.

Great question. In short, platform teams mainly focus on serving internal users (commonly developers) with essential building blocks that fast-track development and offer consistency with end-user UX. Let's use Identity & Access Management (IAM) as an example. As a company introduces a new product, the development team behind it will need to ensure users can securely authenticate and manage access. What IAM offers is a standard company-wide engineering framework for how external users (your customers) authenticate across different company products and how your development teams integrate with this service in a consistent yet secure manner. Depending on where your Platform capability is within the technology stack, Platform PMs could have a different level of exposure to end users while their internal user focus remains unchanged.