The #1 Answer in Product: It Depends [Mind the Product]

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.

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.

Because product management is the practical application of common sense, and the first answer to any question in product is almost always: it depends.

Common sense is not so common.Voltaire, 1764

It Depends on the Context

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.

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 – 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.

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.

It Depends on Balance

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 – without one or the other your picture is incomplete. And Discovery vs Delivery is a false dichotomy – 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).

Balance is everything. While I’m a huge advocate of collocated teams let’s face it – 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.

It’s a Spectrum

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.

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.

The post The #1 Answer in Product: It Depends appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2018/08/the-1-answer-in-product-it-depends/