post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Building for change: When transformation and product management meet

Product Development

What are product features? Definition, examples, and 5 types

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! 🎉

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Lessons from my first year as a Prod Ops Manager

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

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="https://www.mindtheproduct.com/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="https://www.mindtheproduct.com/wp-content/uploads/2018/08/product-managers-tools-1024x683.jpg 1024w, https://www.mindtheproduct.com/wp-content/uploads/2018/08/product-managers-tools-300x200.jpg 300w, https://www.mindtheproduct.com/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>

core/freeform

Agile Product Development

Better value sooner, safer, and happier by Jonathan Smart

Building Successful Product Development Teams, by Simon Colmer

How to be a Successful Product Owner, by Ninon Laforce

Out of the Fog by Holly Donohue

How Design Thinking, Lean, and Agile Work Together by Jonny Schneider

Lean, Agile, & Design Thinking by Jeff Gothelf

Tales of two Continuous Loops by Tim Beattie

Agile With a Capital A Might not be Best by Morag McLaren

How to Apply Lateral Leadership in Agile Environments by Tim Herbig

Owning Agile by Jeff Patton

The #1 Answer in Product: It Depends

ProductTank Ahmedabad

ProductTank Bangalore

ProductTank Berlin

ProductTank Oslo

ProductTank Des Moines

ProductTank Bangkok

ProductTank Abu Dhabi

ProductTank Helsinki

ProductTank Pune

ProductTank Kraków

ProductTank Cardiff

ProductTank Mumbai

ProductTank Johannesburg

ProductTank Tauranga

ProductTank Bielefeld

ProductTank Vilnius

ProductTank Timisoara

ProductTank Stockholm

ProductTank München

ProductTank Düsseldorf

ProductTank Birmingham

ProductTank Norwich

ProductTank Heidelberg

ProductTank Malmö

ProductTank Barcelona

ProductTank Newcastle Upon Tyne

ProductTank London

ProductTank Perth

ProductTank Málaga

ProductTank Tokyo

ProductTank Braunschweig

ProductTank Edinburgh

ProductTank Pittsburgh

ProductTank Vienna

ProductTank Bristol

ProductTank Washington

ProductTank Raleigh

ProductTank Brno

ProductTank Paris

ProductTank Orlando

ProductTank Montréal

ProductTank Hong Kong

ProductTank Charlotte

ProductTank Exeter

ProductTank Manchester

The #1 Answer in Product: It Depends

Martin Eriksson

Read more

Comments