post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Martin Eriksson has 25+ years experience building world-class online products in both corporate and start-up environments for global brands such as Monster, Financial Times, Huddle, and Covestor. He is the Founder of ProductTank, the Co-Founder and Curator of Mind the Product, and a Product Partner at leading venture capital fund EQT Ventures. He is also the author of the best-seller <em>Product Leadership, How Top Product Leaders Launch Great Products and Build Successful Teams</em> (O'Reilly, 2017).

Martin Eriksson

<p>The internet lends itself to binary positions: you’re either for something or against it, advocating it or decrying it. It’s not just Twitter’s 280 characters that limit us to this black and white thinking, most blog posts and conference talks seem to follow the same trend.</p>
<p>And I’m not even talking about politics. Waterfall vs Agile. Qualitative research vs Quantitative data. Remote vs Colocated. Discovery vs Delivery. Roadmaps with dates vs Roadmaps with no dates. Usability testing vs A/B testing. VC funding vs Bootstrap. The list goes on forever, and the debates are never-ending. But at the end of the day these are all just tools in a toolbox. The best product people don’t think about them as binary positions but treat all methodologies and orthodoxies as tools, and know when to pick each one out of their toolbox in order to solve a specific challenge.</p>
<p><a href="https://unsplash.com/photos/mQgVyUC0V-I" target="_blank"><img loading="lazy" decoding="async" src="//wp-content/uploads/2018/08/product-managers-tools-1024x683.jpg" alt="Product Management Tools in a Tookit" width="1024" height="683" class="aligncenter size-large wp-image-13634" srcset="/wp-content/uploads/2018/08/product-managers-tools-1024x683.jpg 1024w, /wp-content/uploads/2018/08/product-managers-tools-300x200.jpg 300w, /wp-content/uploads/2018/08/product-managers-tools-768x512.jpg 768w" sizes="(max-width: 1024px) 100vw, 1024px" /></a></p>
<p>Because product management is the practical application of common sense, and the first answer to any question in product is almost always: it depends.</p>
<blockquote><p>Common sense is not so common.<cite>Voltaire, 1764</cite></p></blockquote>
<h2>It Depends on the Context</h2>
<p>Every company, team, product, and market is different so blindly applying any tool, process or methodology every time is simply not going to work. What works for a startup won’t work for a corporate giant. What works in a new market won’t work for an established market. And so on.</p>
<p>So even the age old (at least in internet time) debate on agile vs waterfall often misses the point. If you’re shipping something like a medical device, or that interfaces with a partner and needs to hit an external deadline, or that is a solved problem and simply needs to get done because of regulatory requirements then by all means go waterfall. Define the crap out of the work and project manage it to a date. But if you’re exploring a new market or product then of course that approach won’t work &#8211; because you don’t know what you don’t know. So in that context applying discovery techniques and iterative development is of course the only solution.</p>
<p>And context is everything. I recently ran a workshop for a team focused on proto-personas (where the team brainstorms personas based on their intuition, not hard data). Are proto-personas the best way to segment and define your customer? Of course not. But for this team it was an incredibly eye-opening experience as they’d never even discussed who their customer was before. So in this context we couldn’t have started with data-driven, user research-defined personas because the team wouldn’t have seen the value or invested the time. In this context we had to start with something imperfect simply to start the right conversations.</p>
<h2>It Depends on Balance</h2>
<p>Some things aren’t black and white because you simply need both. A nice melange of grey. For example, we all know quantitative data tells you what happened, but qualitative data tells you why &#8211; without one or the other your picture is incomplete. And Discovery vs Delivery is a false dichotomy &#8211; you need to discover what to build before you start building (although this hasn’t stopped a surprising number of companies from getting stuck in a build-build-build cycle).</p>
<p>Balance is everything. While I’m a huge advocate of collocated teams let&#8217;s face it &#8211; we all work remote already. We’re checking emails at home, listening to podcasts on our commutes, slacking from our holidays. The only question is how much time do we spend remote? Some people work better from home and some from the office, yet the remote advocates would have you believe it’s better for everyone and in every situation. The practical application of common sense suggests we need to find the right balance. Maybe everyone has to be together during big discovery phases and experiments, but can work remotely when we’re just building and delivering? Finding the right balance for your team and how they work best is simply better than forcing one or the other approach.</p>
<h2>It’s a Spectrum</h2>
<p>Everything exists on a spectrum so there are no black and white answers, which means the answer is almost always: it depends. This is especially true in product where you’re probably looking at the intersection of several different spectrums. From company size to company maturity, from stage of growth to position in the market, from what motivates your team and how they work best, all of these spectrums affect how you best work together. Which means that understanding where you are on those spectrums is the most important skill a product person can learn, so that you know when to pick which tool from the toolkit.</p>
<p>So let’s stop arguing about which tool, methodology, or orthodoxy we think is best, and let’s start having an honest conversation about the contexts within which those tools are appropriate.</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

The #1 Answer in Product: It Depends

Martin Eriksson

Comments

Read next