Should you split your product managers and engineers across various locations? How do you distinguish between mission driven and mercenary developers? Are roadmaps really worth it? How do you set up the right OKRs?

Last week we had the pleasure of hosting Marty Cagan, author of Inspired: How to Create Tech Products Customers Love, who answered a few of these questions in our monthly AMA. Marty, the founder of Silicon Valley Product Group (SVPG), is widely recognised as the primary thought leader for technology product management. Starting his career as an engineer at HP Labs in 1981, he then became VP of Product Tools at Netscape, followed by VP Product & Design at Ebay, before founding SVPG in 2002.

As Marty’s entire career has focused on tools and processes for development teams, we were keen to gain some insight from him on what it means to be a product manager. To watch the complete AMA click here. If you are interested in learning more, then be sure to give Marty’s book “Inspired: How to Create Tech Products Customers Love” a read. Here are a few interesting highlights from last week’s session.

Product Teams: How to build and monitor them?

According to lean startup lingo, most product teams are built around a “core” or a “durable product team” (or a “squad” as they’re referred to at Spotify). These are cross functional teams that bring in product managers, designers, engineers, plus any necessary support, such as data scientists and analysts. They are empowered teams, skilled at finding the best solutions to any problems they may encounter.

They are horizontal teams and although they may usually have a wide scope, each role comes with its core function. Engineers solve technical constraints, designers solve user constraints, while PMs solve for business constraints and ensure that everyone understands the context. Teams need a common vision to remain aligned with the overall organisation, but how exactly does you move an organisation towards best practice?

One way is to engage in more customer discovery programs, where you focus on a particular set of customers and then build the best features for them. It is great for sales teams, your team understands the client, and you get a set of customer references ready by launch day. A more mild version of this is simply to bring an engineer to each customer visit. As far as measuring your team’s outcomes, Objectives and Key Results (OKRs) are helpful but only when the teams decide what they commit to. Keep the objectives qualitative (ex: integrate with Stripe), the keys quantitative (lower churn by 1% by end of quarter). For more information on this make sure check out John Doerr’s “Measure What Matters”.

Roadmaps: why are they such a pain?

Roadmaps don’t have to be problematic...but they tend to be. You can’t have empowered teams, when they have a set of features to deliver on each quarter, that they have had no input into. On top of that, most studies show that most features on roadmaps don’t actually work, and the process doesn’t help deliver on budget. Stakeholder driven roadmaps (those with a top down decision framework), tend to emerge from “command and control” style companies, while those with flatter and more independent structures usually focus on outcome over output.

List of ideas are harmless, but if you attach commitments on them before understanding their value, you’ve limited the ability to improve your product. Not to say that you shouldn’t have roadmaps at all, but strive to make them shorter and more outcome versus output based. Focus on building empowered product teams that can go out and find areas of improvement on their own. Give them the time to juggle between discovery and deployment, and set a common product vision (what you want to create over the next few years), strategy (the steps to get you there), and principles (based on the nature of the products you are building) to maintain cohesion.

Growing Pains: how do you go from one to fifty teams?

As a company grows, it changes, and scale usually shines a light on pre-existing problems. Natural selection will tend to ensure that only companies with potential experience this pain, but a strong product focused culture is crucial to survival. At the startup stage, a company is focused on finding product market fit. Once it enters growth stage, it will focus on building a sustainable business before establishing itself as an enterprise leader. A company can and should be in multiple stages at once. You can be in growth but launch new startup stage products in ancillary business units. Amazon, is a perfect example. It has both enterprise scale and constant innovation. It regularly starts new businesses; those that manage to get to PMF are very efficient and some are now bigger than the original Amazon itself. Growth stages aren’t discrete categories in environments that consistently seek to create new value for customers.

We really enjoyed spending a bit of time with Marty and hope that by watching our AMA you will find it useful too. Marty wrote his book to minimise the chasm between the best product teams, those with the right mindset and techniques, and everyone else. When he wrote the first edition of his book, nearly ten years ago, he was convinced that this gap would eventually go away as the adoption curve faded. Unfortunately it has only widened and he now spends most of at SVPG showing companies how the best teams operate and why they should switch to a more modern approach.

If you found our AMA useful, make sure to check out our next one which will take place on 2nd August and feature Mark Roberge, author of best seller "The Sales Acceleration Formula." You can register here.