Software Product Development

This talented street performer might have worked on his act for months, or even years, but it’s only when he senses the audience’s reaction that he’ll know if he’s delivered value.

Value can only be approximately measured using money: value is ultimately about what we would voluntarily choose to do.

If value was only about money, then the open-source software movement wouldn’t exist. Nor would Wikipedia, and nor would so many other valuable things. Furthermore, the mere fact that a person pays for something is insufficient to explan the value that the person is harvesting during their experience.

When it comes to a street performance, if the audience feels that the time they’ve invested has been worthwhile they’ll want to repeat the experience on another occasion and they’ll be motivated to recommend their experience to friends.

But there’s something else: the performer also needs to feel that years of practice in cold cellars and on derelict baseball courts – plus the injuries along the way – have been worth it.

It is only during the performance that these complex and subtle value judgements are made.

For each and every member of the audience, as well as the performer it’s all about their personal experiences and the perceived value of those experiences.

And it’s exactly the same when it comes to software products.

The street performer is analogous to a technological system built by a software product team, whose purpose might be to entertain, inform or allow some task to be accomplished.

The magic of software is that the software product team need play no role during the performance: the technological system the team has built will mindlessly perform its act according to a script that the team wrote.

So what about the thoughts, emotions, feelings and behaviours of the audience during the performance – the time when the team’s ‘automaton’ is performing its act?

The painful answer is that many product teams seldom know. Even more painful, some teams seem not to care.

And this is one of the biggest problems in software today.

Truly magical software experiences occur when four elements are brought together in the right way: a product team, the technological system they have built, an engaged audience and an exchange of value that works for everyone.

A special blend of all four elements is needed for sustainable success.

The purpose of software product development is clear: one group of people (a product team) works to build a technological system that then performs a ‘show’ in order to entertain, inform or help another group of people (the ‘audience’).

Sadly, in too many software product development situations, this purpose has become clouded by a dense constellation of technological tools, frameworks, methods and more that were supposed to help us put on a great show but are increasingly obscuring what software product development is all about:

• We spend hours documenting our thinking using high-level programming languages like Python and Java;
• We spend even more hours using sophisticated task management tools like Jira;
• We have been trained to use powerful software project management frameworks like Scrum, and,
• We use design systems like Material that help us build effective user interfaces.

All of this ‘stuff’ was supposed to help us build technological systems that would allow us to put on a great show. But, today, such an intense focus on complex tools, sophisticated frameworks, technical methods, robust processes and a fountain of technology has left insufficient time to observe the show and understand what the audience thinks.

Compounding the problem is the use proxies to understand our audience:

The insights harvestable by scrutinising a Tableau dashboard are categorically different to those that will arise from deeply engaging with the human audience to understand the jobs, journeys and mental models. It is only by engaging with real people that a product team can understand why the the audience turned up for the show, what it expects and what it thinks afterwards.

To sum up, the tools we’ve built to help us put on a great show have made us lose sight of our purpose and have tricked us into believing that we can fully understand our audience by using crude proxies like bar graphs, pie-charts and tables.

This needs to change.

Compared with roles like engineering, marketing, sales and finance the role of product management is still being forged – in the fire of experimentation.

But after thirty years in the making, product management still lacks a clear value proposition.

Take a moment right now to write down the one valuable thing that product management does that no other established role does?

When you’re done consider how many product people would agree with your answer? And what about people working in sales, marketing and engineering – would they also agree with your definition?

The debate rages about what product managers do: we have growth product managers, technical product managers, UX product managers, go-to-market product managers and, of course, we have product managers who see themselves as the ‘CEO of the Product’. Most recently we’ve seen the emergence of product managers who specalise in product operations.

But none of these experiments have hit the spot. And, deep down, most experienced product managers know this.

Survey after survey shows that product managers are confused about their role.

The default way of working for too many product managers is that they:

• Focus on building technological systems (wrongly regarded as products);
• Act as de-facto project managers (because Agile wrong-think has worked to marginalise or even demonise project management);
• Spend endless hours dealing with the Hell of Jira (where engineers struggle to understand the user space via cryptic tickets, useless personas and invented user stories).

And all the while being a ‘Mr. Fix It’ who’s on standby to jump on any passing problem – something justified by those who view the product manager as the ‘CEO of the Product’.

Sure, a lot of good work is being done by good, committed people.

But how much of that work is uniquely value-added? How much of it could be done by existing organisational roles?

Because product managers spend most of their time building technological systems and doing jobs that others should do they do not have enough time to deeply understand the user space and then use that understanding to develop a compelling vision for the product – both of which are fundamental when it comes to directing a software product development activity and motivating a product team.

In the future, the product management role will need to be rebalanced with more focus being placed on the user space, which means understanding user jobs, journeys and mental models.

Ultimately, the USP of product management will be to actively manage the exchange of value between the user space and the company space – which is what’s needed to put on a great show.

An established physicist will be skilled in a range of subjects: applied mathematics, Newtonian mechanics, optics, general relativity, nuclear physics, electromagnetism etc.

That person will also be familiar with the considerable number of often colourful figures whose discoveries represent the current axiomatic foundation of physics – people like Bohr, Heisenberg, Einstein, Maxwell, Faraday, Ampere and many more.

In order to practice physics to a high standard you need an adequate depth and breadth of knowledge which can only come from deeply understanding many subjects and their associated histories.

So what about the field of software product development?

What about topics like user-centered design, object-based design, Lean, Scrum, prototyping, new venture development, business analysis and more?

A strong understanding of these topics inform directly on the work the product teams do every day.

But have we studied them as well as an accountant or engineer would? Let alone as how a physicist would?

Do we see ourselves as a collection people working to convert software product development into a serious profession?

Or are we happy to develop our understanding by casually grazing on opinion-based content posted on sites like LinkedIn and Medium where there is an endless supply of cynically manufactured content, catchy but throwaway one-liners, random 2×2 charts, glossy infographics and superficial heuristics?

Is this to way to convert software product development into a serious profession?

I’ve come to the view that the many topics that define our field should be formally taught as courses, in a similar way to what happens at good universities where students develop competence by understanding the theory, doing course work, living case studies, working on industrial placements and passing examinations.

Maybe those who already have a Bachelor’s degree and aspire to gain a professional status would be interested in a qualification, such as a Masters in Product Development (MPD) – modelled on the established Masters in Business Administrtation (MBA).

And for those already in the workplace, then perhaps an ‘Executive Masters in Product Development’ (EMPD) – modelled on an Executive MBA (EMBA) – might be a good idea.

Yes, people who want to make a career out of developing software products should have formal training and they should be able to demonstrate their competence by passing a set of tough examinations, where a ‘pass’ is by no means assured.

Any so-called ‘training programme’ that results a guaranteed certificate is useful in the sense that it demonstrates participation, but it cannot deliver the professional competence that the field of software product development so desperately needs.

After all, you don’t get to put on a fantastic show unless you’re willing to put in the years of hard training needed to perfect your act.

The primary mission of Divergent Product is to play a role in creating the educational and examination infrastructure needed to develop the first generation of product development professionals.