You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 7 minutes
An early AI founder shares what it takes to build a successful business, including addressing real customer pain points, focusing on outcomes, and building team autonomy into the org’s foundations.
Placing a meaningful and well-loved product at the center of all operations is paramount to creating a growing and scalable business. The importance of empowering expanding teams of product managers to drive that growth can’t be understated either. As CPO and co-founder, my role involves keeping the business and teams true to those aspects in a sustainable way.
This approach helped me evolve our initial AI product – which was designed to record and transcribe sales calls – into something that can analyze those calls to predict how likely a deal is to close and even estimate its value. Plus, it lets users ask questions like, “What did we discuss with this client?” or “What’s their main concern?” and instantly get helpful insights from past conversations.
Addressing pain points rather than adding features
Build teams purposefully. Understand your specific customer needs first and then organize product teams to solve them. This sets the correct tone so that everyone is laser-focused on that goal.
Solely focusing on “adding features” can skew focus towards builds that are impressive rather than genuinely impactful.
Our ‘pod’ structure
Initially, we split people into “pods” centered around specific customer needs. Each pod was made up of a product manager, designer, and engineer. In the past, I’d seen teams organized according to specialization (like backend vs. frontend or platform vs. applications) but felt this prioritized technical capabilities over impact.
As the company’s scaled, our “pod” approach hasn’t changed significantly; they’re still made up of a blend of skills aligned to tackling specific problems like sales forecasting (projecting how much revenue a sales team will generate) or conversation intelligence (the use of AI to analyze customer interactions to help understand what’s working, what’s not, and what to do next). These pods naturally align with certain users, like sales managers, and look to improve workflows for them, like reviewing the risk in their teams’ deals.
Now that we have a larger product engineering team, we assemble these pods into “groups” that roughly match up with a product. The products are typically aligned with specific analyst-defined categories, such as conversation intelligence, sales engagement, or sales forecasting. By aligning our team in this way, we can stay hyper-focused on meeting real demands as opposed to building what we think our buyers will find useful.
The system in practice
We had a pod assigned to a new sales product. That pod was able to meet regularly with several beta-test customers and iterate on the product based on their feedback. Within a week, an updated version of the product was ready. A more traditional method where cross-team back-and-forths, like back-end specialists liaising with front-end counterparts, would have been far slower.
More like this
Outcomes over speed
The focus of teams should be on what customers get rather than when they get it. There’s a balance to be struck here, of course, as you can’t keep users waiting in limbo for an upgrade they’re crying out for. However, I’d rather deliver something that takes a bit more time to build but works brilliantly than something that’s hastily put together for the sake of meeting artificial deadlines.
Flexibility over scrum
A focus on outcomes puts a premium on flexibility, which is largely why I don’t believe in the traditional scrum methodology that divides work to be achieved into time-boxed periods known as sprints. Each sprint lasts no more than one month, typically around two weeks. I feel it falls short in two major ways.
- Splitting time into rigid sprints makes fitting real-time feedback into the development process cumbersome. Imagine you’ve just delivered an early version of a capability and have moved into the next sprint. Any feedback received on the first capability can’t be easily applied without replanning a phase of the capability already in motion. Instead, we want the flexibility to incorporate feedback on the fly.
- They require a scrum master to oversee, which I believe is superfluous. Product managers represent the customer’s voice and an engineering leader is responsible for the build part – that’s all you really need.
Don’t rush to fulfill a founder’s vision
Founder-led product teams like ours are also susceptible to other scenarios where a desire for speed gets in the way of delivering value. They can fall into the trap of trying to achieve the founder’s vision as quickly as possible, but again, this means putting the customer in the backseat, which slows growth.
While our company was originally designed to apply machine learning to sales calls we recorded, we soon began to receive requests for new functionality we’d never considered. One of the earliest was a call for scorecards so managers could visually track teams’ performance – how much time they were spending on calls, how well they performed, etc – and coach them according to their specific, individual metrics.
We could have mindlessly pursued my and Amit’s – co-founder and CEO – original idea, but the entire team understood the need to balance that original strategy with evolving our product according to the real-time input customers were feeding us on competitive and market changes. That mentality still runs through our process today.
Extreme autonomy
I believe that with the right structure around them, individual teams should have a high degree of autonomy in addressing the problems of customer profiles they’re assigned. It lets them move faster to innovate and apply customer feedback without bureaucracy hampering them.
Building freedom into the foundations through annual planning
We build an autonomous culture into our foundations using a W-shaped framework, often during our annual planning phases. In this approach, management establishes the top company priorities, which are then filtered down to product and engineering teams. These teams then determine how those priorities align with different areas and the resources they need – if they need to reallocate certain pods, for instance, that’s their decision. In practice, this means a pod initially assigned to tackle sales forecasting might end up working on a different, or completely new aspect of a product if that’s where the greater need is.
Only once these teams have their plans and product pillars in place do they return to the senior team for feedback. The next time management gets involved is when product descriptions and timelines are defined.
This quickly comes together to form a plan of attack for the year ahead. Often, the plans for the first quarter are the most certain, with the second quarter slightly less defined. Q3 and Q4 consist of a broader strategy that lets us adapt based on learnings we compiled earlier in the year.
Working autonomously with design partners
I also believe product teams should have extreme autonomy over the way they use design partners, an approach that was a key aspect in our early growth and remains so today. We worked with 12 partners when we were initially building the product, who gave us invaluable feedback on how we could improve it. Now, all our 20+ product managers work with as many as a dozen of their own design partners, who still perform that same role of validating early ideas and helping to refine them.
As a result, the people facing the problems we want to solve are the ones making sure our solutions work. Whether developing your minimum viable product or upgrading an existing one, encouraging teams to engage directly with users means they’ll quickly become more attuned to their needs.
As senior leaders, we may have our opinions for how things should work or look, but if that’s not aligned with what real users need to do their jobs better I’d much rather our managers and engineers take their feedback than mine.
Final thoughts
Neither Amit nor I wavered from our belief that our product and commitment to supporting revenue teams had potential. By balancing our ideals with users’ needs and building our entire development framework around maximizing customer-centricity, we had faith that eventually, people would begin to see the vision for our company as clearly as we did.
This belief extends to the next entrepreneur looking to turn their idea into a reality. There’s no single great way to build great things, but these strategies can serve as a great jumping-off point.
