I’ve been reading different articles about product management, service design etc. for a while (well, it’s a part of my job). It seems that after the agile manifesto was introduced to the world in 2001 (or so, sorry for not cross checking, just remembering the year), that now in 2021 we’re still trying to understand the heart of all it.

There are loads of information, tools, frameworks, good practices, methodologies going around it. I still think that many companies don’t see how it could change the way they do things when being agile instead of practicing a small part of it in the implementation phase.

Currently in Finland we have ongoing “software industry is sexy business and you can make a fortune in coding”-campaign because of we have a “huge shortage” of developers. I kind of disagree on this.

Yes, it’s hard to find developers. It’s really hard to find good developers, who can create quality over quantity and do the right things along doing all the project/product management, taking care of support and customer needs. Hope you see the sarcasm in this.

The solution seems to be adding more educational places, coding workshops and 12-week programs to get anyone who is interested to get to software industry fast. Too bad that the employers usually want the ready package and are not necessarily ready to invest huge amounts of work to get the developer up and running as efficient as he/she could.

Inefficiency vs. need for workforce?

I love most of the programs, because anything that makes people more interested about the software industry is a good thing, but will it solve the “shortage”?

No, I don’t think so. I think the real problem is deeper, it’s overall in the inefficiency of software companies, and THAT is something we can tackle to ease up the shortage.

Software industry is relatively young industry related to for example manufacturing industries, where things are automated and as lean as possible. It’s mostly effective. In software industry I bet that everyone has seen some of the next examples:

• Software was created according to customer needs and everything was accepted in common understanding. It didn’t solve the problem or needed rework to make it work.
• Critical semantic software problem wasn’t found out until 1 year of development, but when the software started to get real use, it was evident, that it just doesn’t work.
• Software has only one or two guys who know how it works, it only can be developed by the two guys. Hell, it even only can be trained and managed totally by those two.
• The product is tailored for several customer, it has gazillions of parameters that are in at least some sort of contradiction with each other — making the development really hard. Something I call “Butterfly effects” are common (fixed something, broke something totally different).

Everyone has some of those examples in their back pockets, and there are a lot more of them. The point being, it’s not about the available workforce, it’s about doing the right things and preferably doing them in a quality that can handle improving it.

Hiring more developers to make it work won’t do the trick, it solves the wrong problem and possibly makes the problem itself worse.

Product management to the rescue!

I think it’s not even about the product management, it’s about the mindset. Product management just is the place where you can do a lot to it. Really forget waterfall in any way.

It’s not agile to minimize testing or reduce work from documenting. It’s about doing the right things in iterative manner throughout the company. Don’t try to do perfect things at once, since everything changes sooner or later.

When you get to the right mindset of failing fast, suspecting everything (paranoia is a virtue) and implementing only minimum viable features/products, you can remove a LOT of unnecessary work and concentrate the workforce on doing things once instead of doing things multiple times.

Why the product management? I know that product managers are not that valued. Many of the companies don’t even have one. A good product manager is the one who knows the customer needs and can challenge them.

They work in every aspect of the company, whether it’s the sales (input + feedback), training, customer support, developers, marketing or just product ownership.. you name it, there’s always a role for product manager who can orchestrate the product and it’s future plans.

This is something that isn’t trained in Finland, which is a shame, because when the product is managed correctly, the whole work is more focused and if done correctly, it really multiplies the efficiency of how things are done. This results in less unnecessary work, and need for less workforce in the end.

For example I know that customers have a “bad habit” of providing solution as a requirement. If these are processed example with user journey mapping, it can proof that the root reason wasn’t the requirement and the real problem was elsewhere.

When the problem is discovered, it can be story mapped with the team. When you get to the point where you and the implementing team have a shared understanding, you can form acceptance criteria. And against that acceptance criteria you can create acceptance tests to a living documentation. If you fail at this point, you just saved a ton of work implementing it!

I could write a book about it, but the point being: Requirements should always be assessed by their business value and how they affect on company’s strategy. When this is done, you are going in the right direction.

Requirements should be validated and verified early and failed before development, so that you know you’re doing the right things — it should be done in the cheapest possible way (for example prototypes, pretotypes or minimum viable experiments).

When in development, do as little as you can to provide minimum viable solution. Don’t use ten page requirement documentation, share the understanding of the problem and slice it to small viable solutions.

Do first step, validate it, improve. Iterating things in this stage is something a product manager can do! You probably get what you want instead of what has been understood of the written description. I don’t go much further in the process with this, since next you need a good team of developers who understand how to work agile!

You know, the thing I talked in the beginning. Experienced developers, who can do TDD and create quality over quantity, which really needs a mindset of it’s own.

So, what this story was all about. I think that there really isn’t shortage in developers. There is a shortage of understanding how to do things so that they are as agile as possible.

A shortage of mindset of suspecting everything and failing as early in the process as possible to do the right things instead of doing things right. There is a shortage of product managers that can drive the company in the direction of the strategy — doing the right things efficiently, not twice.

So, if you have a fellow in your company who has this mindset and can alter the others. Give him a tap in the back and allow him to (cross)pollinate the organization culture. If not, probably you should find one — after all, it might help you start doing the right things, instead of getting you buried under the “developer shortage”-problem.