Building better software: leveraging product management principles.
How can devs take a trick from PMs’ books?
As my followers will know, before I became a Developer I was a Product Manager. Devs and PMs often think of each other as “the other side”, but really the roles have more in common than you might realise — or at least, they do when they’re done well.
PMs have plenty to learn from software developers. But equally, we have a lot to learn from them. Above all, PMs are experts in listening to users. “User centric” is an adjective that’s cheap to use, but it’s a discipline with specific rules and methods — and not a simple one to master. Here’s some ways to take a leaf from their books:
Names and Branding Matter
Comments in code divide devs. However, everyone is in agreement that names should be logical and legible. I’d like to take this a step further and propose that you make the names you use in your code relevant to your end users. In the way, for example, that most people can instantly recognise what this code (from my version of Hangman) does:
findAndReplaceLetters("e","hello","h-ll-")I’m not (necessarily) advocating a microservices approach or DDD, as I know that can be contentious. And obviously end users will never end up reading your code.
However, names are contagious. I’ve seen lots of projects where component names have “escaped” and worked their way into conversations with users. And that’s not the only reason for taking into account how users speak when building software. Doing so involves a mindset change that will help you create a product that solves their problems better.
User Research is not Optional
Often, the front end of a product is heavily researched. This is an important process, as it stops the creators making assumptions about what users want. There are lots of different tools and methodologies for user research; at some point most of them involve showing users a rough sketch of what you have in mind.
More abstract services like databases and APIs are often neglected when it comes to user research. However, these services also have users. If you’re building a database or an API, it’s good practice to show a rough idea to the people who use these — business analysts, perhaps, or other devs — and see what they think. You can even try more open research — ask BAs, for example, what kinds of questions they’ll want to answer before showing them a sketch of your database.
Extra points if these people are close to end users. Perhaps you could even try asking a PM what they think of your API endpoints. It might be a challenge to explain, but doing so will be a great way to clarify your own ideas. They’ll be delighted to be involved, and you might be surprised what feedback they come up with. This was the approach we took for the ArchDB backend, and it was very successful!
Understand the $ Value of your Decisions
As a PM, I was fond of using something known as Cost of Delay to help make decisions. Basically, this calculates the possible revenue over time from one decision or another versus how much effort each will take to decide what’s best. It’s wildly approximate, of course — but sometimes even seeing something in rough can help you identify trends.
Software these days is generally not considered a success unless it’s profitable, and Cost of Delay can help you work out which path one decision or another will take you on. I’ve seen it used particularly successfully in DevOps scenarios (for example, to argue against using sharding), but you can also use it for refactoring decisions. Is it better to rebuild from the ground up or maintain what you already have? Which will gain most revenue in terms of speed of pushing out new features, reduced bugs, etc. for the effort you put into it?
As well as helping you make your own decisions, this will give you a huge advantage when communicated them to the rest of the business. There is nothing worse for Product or Sales than having all projects put on hold due to refactoring. If they can understand the financial advantage involved, they’re likely to feel a lot better about it.
Learn to Collaborate (Properly)
As a PM, you truly see the value of channelling the whole team’s energies into suitable activities. You also see that a desire to contribute, but not knowing how, can very quickly turn into chaos. As a dev, you’re often both an enabler and a leader of sorts. Learn how to live up to the role by channelling the rest of the team’s energies appropriately.
One excellent way to get the whole team rowing in the same direction is by getting them involved in TDD. When I was working at Factorial, I was involved in a successful initiative to get Product involved in writing requirements for E2E testing (credit to Josep Jaume for this approach).
Getting the whole team involved in pre-launch QA can also be very successful, as it allows you to collect feedback on multiple devices and in multiple environments before a project goes live. Just make sure you organise it properly. For example, you might like to maintain a spreadsheet (or Trello/ClickUp/Jira board, whatever stakeholders can use most easily) with columns indicating issue, reporter name, device type, dev team response, etc. You don’t need to do everything on the list — work with a few key stakeholders or your PM to agree on what’s the most important.
Resources
- Black Swan Farming explain Cost of Delay
