What company wouldn’t love to have its product development efforts be more effective? Be able to release new products and product updates with fewer delays and overruns, with higher quality and at lower cost? And be sure of the product-market fit, too?
Many companies spend inordinate amounts of time, effort and management attention on just this. And yet reap little in the way of benefits from that investment.
Why is this? What are the blockers (constraints) frustrating these ambitions?
In a nutshell, the issues that plague SIPD seem obvious. They’re mostly the same issues that plague all forms of collaborative knowledge work. Issues compounded by the gulf between conventional or traditional work and the new world of work (i.e. the world of collaborative knowledge work) – a new world distinctly unfamiliar to most in the world of work today.
Creating, sustaining and continually improving effective ways of New Product Development requires the efforts, commitment and active participation of everyone in the organisation. It’s not something that can be delegated, offloaded or left to just one department, function or silo.
If you’re in the business of supplying IT services, especially software and product development, to your clients, you may be getting uneasy (again). Agile software development, and its close cousin, DevOps, are the latest in a long line of approaches promising to solve the “software crisis”. And like the many approaches that have gone before, their faults are beginning to show, and the chickens are coming home to roost.
Ask a hundred people what’s their definition of a “top software developer” and you’ll likely get a hundred different answers. Many definitions may cluster around “someone who can make the computer jump through hoops”, i.e. a technical virtuoso of some sort.
If you’re in business for anything more than a one-hit-wonder, you may have given some thought to your next product. Albeit probably not much more than a few cursory thoughts, given the attention that you current product(s) demand of you.
Some lucky few may have moved from the idea of economies of scale, maximising utilisation, etc., to the idea of flow. Flow of products from raw materials to finished and sold goods (or services). And flow of product ideas and new features into those products and product lines.
Scaling Agile is one of those oxymorons that has, nevertheless, consumed endless column-inches and hours of debate. I have no time for it. Agile was meant for development-in-the-small. For teams of five to seven people, give or take. Even at that “scale”, I have serious reservations about its efficacy and effectiveness.
So you think you have a brilliant idea that will become a hugely successful product or service. Congratulations!
“But how do you turn that idea into a well considered, structured game plan for how you will turn your concept into reality?”…
