There is one thing I can say with certainty after over a quarter century of building software products – it’s complicated!
It’s complicated because there is no set formula. Every time you start out creating software, whether it’s a custom application for a specific use – or a product used by many in different ways – you are going to need to spend a lot of time figuring out what to build, decide how you are going to build it – and gather in the different things that you will build it with.
In other words – you are going to need to throw in product management effort, stir in engineering – from back end to front end to middleware, and finally put it all together in a big pot of enterprise architecture – and watch it carefully till the first version of the product emerges. And o by the way, you are not done yet … because as soon as the first version is ready, your users are ready for more – so now you have to worry about continuous improvement!
Well, needless to say that you need specialists – folks who are experts in product management, architecture, engineering and processes – all working together to make this happen. But I would also say that if you are the captain – the gal or the guy who is responsible for making it all come together, who happen to have a title of a development lead, delivery manager, director, CTO etc. – then you kind of have to know enough about how all of these things work as well. Maybe you started out as an engineer, or a product manager, or a subject matter expert – and then did very well, rose up the ranks and are now at a place where the buck stops – your expertise will still be an advantage, but it will not be sufficient. In fact I would argue that you don’t need to remain an expert in your own area any more, but you will need to have enough knowledge to be able to have constructive conversations with every member of your team – regardless if they specialize in design thinking or domain driven design, microservices or Kanban, CI/CD pipeline or planning poker …
With that in mind, I would like in this column to start discussing this entire body of knowledge – at a level that makes sense for a product development generalist. My hope is that I am able to bring in some important topics, and discuss them in enough details that would help someone who is new to the function – whether it is part of product management, enterprise architecture, governance – compliance – risk management, agile practices, project management – or anything else that is relevant. Iw ill publish one blog a week on one new topic, categorize it under the ‘Generalist’ topic – and hope that it helps someone. Happy reading!