post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

Sunday Rewind: Whose job is it anyway? The rise of Product Ops and why it deserves to be an independent function

Guest Post

Creating metrics that matter

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

How much are product managers getting paid in 2024?

Leading product ops at Delivery Hero with Koen Dubelaar

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

“You’re not as competent as you think” 5 lessons from Ken Chin on navigating a product career (CPO, Spark Networks)

Everything wrong with the product management job market. And how to fix it

With his background in technical editing, community building and product marketing, Chris' approach to product management is inherently centered around user narratives. He spent the first few years of his career working with the B2B developer products, prototyped an experimental technical publishing platform along the way, and then kick-started the Mind the Product platform. You can find him at ProductTank, or on twitter as @camassey.

Product Manager

Chris Massey

<a href="http://twitter.com/PaulLomax" target="_blank">Paul Lomax</a> has been with <a href="http://www.dennis.co.uk/" target="_blank">Dennis Publishing </a>for 5 years, and experienced first-hand the problem of bringing a focus on technology into a business in an industry that has not historically been at all technology-focused.
So how do you do technology if you&#8217;re not a technology company? Part of the challenge is that you&#8217;re unlikely to have senior leadership who are focused on technology. Indeed, the &#8220;problem&#8221; with technology is actually people &#8211; engineers, stakeholders, product managers, and the interplay between them.
The related question to ask when it comes to introducing technology to your business is &#8220;Buy, Build or Rent (or Partner)?&#8221; To start answering that question, Paul suggest you pose two other questions to better understand your needs:
<ul>
<li>&#8220;Is this technology your core business?&#8221;</li>
<li>&#8220;Do you have the competencies to build or maintain this in-house?&#8221;</li>
</ul>
Having planted those seeds, Paul then suggests a few guidelines for working with the various people involved in a business&#8217;s technology:
<h2>Working With Developers</h2>
Bearing in mind that Paul started as a developer, it is perhaps a little surprising that he suggests that writing code should be the last resort! However, as he goes on to explain, code tends to stagnate and proliferate, so you should invest time and energy working out both IF you need to write any code, then exactly WHAT code you need. If you don&#8217;t take these steps, you&#8217;re at risk of accumulating technical debt, which is a whole presentation in itself &#8211; at it&#8217;s core, it&#8217;s a vicious circle, and impedes your ability to deliver future value.
Developers, if left to their own devices, will invent something really cool &#8211; whether or not you need or want it! Sometimes it&#8217;s great, sometimes you just wanted something small and specific &#8211; the trap is that engineers love to create things, and they may be assuming you need something that you don&#8217;t (yet).
As a general corollary to that, developers tend to only see the &#8220;top of the iceberg&#8221; when it comes to the challenges and considerations of building their own solutions. Of course, as Product Managers, we need to help teams see the vast amount of stuff &#8220;below the waterline&#8221;, and make sure that only the absolutely necessary things are being built.
As Paul likes to remind his engineers: &#8220;Developers aren&#8217;t there to write code &#8211; they&#8217;re there to create value&#8221;.
<h2>Working With Customers and Stakeholders</h2>
When it comes to designing a great product, and working with people to ensure you&#8217;re satisfying a real need, customers and stakeholders often fall back on the argument of &#8220;I&#8217;ll know what I want when I see it&#8221;. This just means that you need to do lots of learning work up front to make sure you&#8217;re building the right thing, and avoiding technical debt. That might sound like it&#8217;s against the principles of agile development, but so long as you&#8217;re focused on building very lightweight things for discovery purposes, you can put off &#8220;real&#8221; development for a long time without sacrificing your agile methodologies.
As Product Managers, our role is obviously to act as a communication channel between customers, developers and business stakeholders, and we should not underplay how much value that can add to the organisation. As part of that intermediary role, we should also recognise that we have the ability to negotiate between these three aspects of product. There are rarely true, rigid requirements, but rather problem and solution discoveries to be made. In Paul&#8217;s own words, &#8220;in reality, everything is negotiable!&#8221; &#8211; if we can embrace that and start negotiations around what actually needs to be built and why, it triggers a more collaborative way to search for problems and solutions, and leads to the right technology being introduced to the business.
<h2>Closing Points</h2>
<ul>
<li>Be Agile, and act as a negotiator between the people involved in your products. You&#8217;ll discover a huge amount about what technology actually needs to be added to your organisation.</li>
<li>Adopt Lean principles (go read &#8220;<a href="http://www.amazon.co.uk/The-Lean-Startup-Innovation-Successful/dp/0670921602" target="_blank">Lean Startup</a>&#8220;, but don&#8217;t follow it slavishly), and focus on building minimum viable products and learning.</li>
<li>Adopt <a href="http://kanbanblog.com/explained/" target="_blank">Kanban</a> (or some variation of Kanban). It&#8217;ll help you visualise the flow of work, and ensures that you&#8217;re having detailed and product conversations about the things you&#8217;re trying to build.</li>
<li>Bonus tip: Investigate <a href="http://dannorth.net/introducing-bdd/" target="_blank">Behaviour Driven Development (BDD)</a>. It was the single most important thing Paul implemented at Dennis Publishing.</li>
</ul>

How to avoid screwing up technology (and how product managers can help)

Chris Massey