Let’s start with a question: Which one of these is the most important?
- Fixing existing things
- Improving existing things
- Adding new things
- Researching new things that may or may not go in the bin
Obviously the only answer can be: all of them, or none of them, or one of them, or some of them.
“But that doesn’t make any sense?”, no it doesn’t! Hello, welcome to software engineering and product management, won’t you come in and have some tea?
There have been many attempts, a lot of them successful, at wrangling the problems around delivering software on time, on budget, to spec, etc. Current best practices dictate to use a methodology formed around the ideas of the Agile manifesto: Scrum, Kanban, Lean, all that stuff. In practice they have a few things in common, the most important (I think) being “shorter release cycles, tighter deliverables”. Cool! Who can argue with that? As it turns out it’s everyone.
“But that doesn’t make any sense?”, no it doesn’t! Until you start looking from the outside in as someone who isn’t you.
Your company and thus job exist only because someone is willing to pay for you. Hopefully you have made a good product that solves a problem for the customer. So they will happily pay for your solution, everyone’s a winner!
They don’t (and shouldn’t) really care about your internal roadmap or deadlines, they only care about their roadmap and deadlines. Why should they wait 4 weeks for a tiny feature that will improve their efficiency by 6.4% and get them that bonus so they can finally take that holiday to Acapulco?
The Customer Support Rep
Their only focus is to make the customer successful, if a customer is contacting them with a problem then a failure has already happened somewhere. “Another bug?” They will think, “I thought this was fixed in the last release? Why can’t things just work like they are supposed to? The customer is going to Acapulco soon, I have to solve their problem before they leave otherwise my response time graph will have a spike in it!”
The Product Manager
Forever navigating the shifting sands of short, medium & long term priorities. They will care about trying to get things delivered and ensuring that the things are aligned with the seemingly ever changing priorities. “Acapulco? Do we really need to get that done in Q1?”
They will want to solve difficult and interesting problems by crafting the best code possible using the best, coolest technologies. “Do we really need to implement this feature now? They can just workaround it. I’m busy re-inventing what software is. Acapulco? Is that a new service on AWS?”
What is the solution? I don’t think anyone really knows. If they did then we wouldn’t be constantly at war with the software that we use everyday. A good first step might be empathy, if someone makes a “bad” decision, internally they probably had what they think is a good reason.
Or we wait until we can develop software using telepathy and instead of writing software we dream it. But then I can’t book my flight to Acapulco because your booking system requires that I interact with operators on the spectral plane. Can’t I just touch a button or something? I’ll call tech support.