Paul Lomax has been with Dennis Publishing 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’re not a technology company? Part of the challenge is that you’re unlikely to have senior leadership who are focused on technology. Indeed, the “problem” with technology is actually people – engineers, stakeholders, product managers, and the interplay between them.
The related question to ask when it comes to introducing technology to your business is “Buy, Build or Rent (or Partner)?” To start answering that question, Paul suggest you pose two other questions to better understand your needs:
- “Is this technology your core business?”
- “Do you have the competencies to build or maintain this in-house?”
Having planted those seeds, Paul then suggests a few guidelines for working with the various people involved in a business’s technology:
Working With Developers
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’t take these steps, you’re at risk of accumulating technical debt, which is a whole presentation in itself – at it’s core, it’s a vicious circle, and impedes your ability to deliver future value.
Developers, if left to their own devices, will invent something really cool – whether or not you need or want it! Sometimes it’s great, sometimes you just wanted something small and specific – the trap is that engineers love to create things, and they may be assuming you need something that you don’t (yet).
As a general corollary to that, developers tend to only see the “top of the iceberg” 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 “below the waterline”, and make sure that only the absolutely necessary things are being built.
As Paul likes to remind his engineers: “Developers aren’t there to write code – they’re there to create value”.
Working With Customers and Stakeholders
When it comes to designing a great product, and working with people to ensure you’re satisfying a real need, customers and stakeholders often fall back on the argument of “I’ll know what I want when I see it”. This just means that you need to do lots of learning work up front to make sure you’re building the right thing, and avoiding technical debt. That might sound like it’s against the principles of agile development, but so long as you’re focused on building very lightweight things for discovery purposes, you can put off “real” 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’s own words, “in reality, everything is negotiable!” – 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.
Closing Points
- Be Agile, and act as a negotiator between the people involved in your products. You’ll discover a huge amount about what technology actually needs to be added to your organisation.
- Adopt Lean principles (go read “Lean Startup“, but don’t follow it slavishly), and focus on building minimum viable products and learning.
- Adopt Kanban (or some variation of Kanban). It’ll help you visualise the flow of work, and ensures that you’re having detailed and product conversations about the things you’re trying to build.
- Bonus tip: Investigate Behaviour Driven Development (BDD). It was the single most important thing Paul implemented at Dennis Publishing.
