How Agile is Your Agile?

A good friend recommended to read the article Why Scrum Should Basically Just Die In A Fire by Giles Bowkett. Giles criticizes SCRUM the way it is implemented and lived in most of the companies. Although, I am no big fan of SCRUM but I also see it advantages especially for some smaller projects. Independent of the advantages and disadvantages of SCRUM he is addressing a far more interesting topic: The agility of the processes themselves.

Many companies try to force "agile" into their software departments in a non-agile way. If you want to successfully implement agile processes in a company you should enable and encourage the people to change their behavior and thinking. They should not do things because somebody tells them to do so. They should do things because they are convinced that it is the right thing to do and that it matters.

The best way to find out what matters and what not is by trying, changing, iterating, skipping approaches that do not work, improving processes that are helpful. Companies change like an organism: they grow or shrink, people are leaving, other people are joining, the product might change, the strategy changes, the culture is evolving continuously and so are the requirements for the development processes. A process is meant to support people to achieve goals. A process you put on people without including them is no support. It is a non-fitting pattern into which you try to press people.

If you have a sort of agile software development in your company (and you should have) you need to ensure that you are creating an environment that enables people to change and evolve the agile processes.

Spotify is a great example how this can happen. Independent of how good or bad the described processes might apply for your company, the way they are constantly challenging the status quo is amazing and inspiring.


You can find the corresponding article of that video here and the second part of the video here.

Read More

The "good" PM

Most companies understand that they need a product department or at least a dedicated product manager. But if I screen through the job boards I often get the impression that many companies misunderstand the role of a product manager or often reduce him to a scrum master. I hope that my perspective on that topic can give some more inspiration or might even trigger some changes.

From my perspective the skill-set of a “good” product manager consists of  three columns: domain knowledge, methodical know-how, and soft skills.

“Being the guru” – Domain Knowledge

This skill column itself consists of three pieces: the product, the market and the future. 

Each product manager needs to know his product the best. It should be impossible to ask him a question about the product that he cannot answer. It is like being the chef in your own kitchen. While stirring the port wine sauce you can open the second drawer and grab the can with the nutmeg without even watching. If somebody discusses parts of the product with the PM he always leaves these conversations with the impression that he is just a little grain of dust in the universe.

The product manager has to understand the market. He needs to know all of the competitors and their products. He needs to understand their strategies and the reasons behind. He should be the first one that notices if a competitor is changing the product or a new player is entering the market. The PM needs to understand the requirements and problems of the customers. It is not enough to understand just most of the existing customers but also other potential customer segments.

To make it not too easy for the PMs, they also need to be able to predict the future. They need to understand small changes in the market and predict needs for new products and other opportunities before they even happen. The PM is the trend scout that can create the product of tomorrow which no customer can imagine today.

It is not easy to find a “guru” for your company, especially if what you are doing is no mainstream work. My business is mobile advertising. Guess how many gurus you can find there. The good news is that if you find a smart and open-minded person, a fast learner, that covers the other columns, he will fastly be able to fill that gap.

“Being the carpenter” – Methodical Knowledge

Like a carpenter each PM needs a large set of tools that helps him to master the different challenges of his daily work. These tools can be distinguished into three different categories: processes, research methods, and supporting tools. 
As a part of the process knowledge comes of course a deep understanding of agile development processes like Scrum and Kanban but he should also be firm in the old techniques like the waterfall development (you have to know your enemy) and know about agile anti-pattern. There are more processes he needs to master and own. The information flow from customers via support into the product decisions. The updates and documentations about new products via marketing to the customer.
A product manager should also be firm in project management techniques if this might be part of his job.
When it comes to the extraction of information from customers or other stakeholders, he needs to rely on his methodical research knowledge. He should understand the differences between qualitative and quantitative customer research methods and he should understand the need and usage of KPIs in the overall product development process. A product manager should have some basic understanding of statistics. Without knowing what significance means he might draw wrong conclusions from statistics he is imposing. A product manager should understand the differences between structured, semi-structured and unstructured interviews and be able to apply the right methods for the right situations. If he is asked if he would like to setup a focus group or a key informant interview in order to derive some conclusions there should be no hesitation in giving the right answer.

Fortunately, there are lots of different tools out there that support the daily PM’s work like

Silverback (http://silverbackapp.com/) or Mixpanel (https://mixpanel.com/) and the PM should be able to name at least a few of them.

The good news is that finding a carpenter is not as difficult as finding a guru. The base of becoming a first class carpenter is a solid education and a lot of experience.

“Being the diplomat” – Soft Skills

A product manager needs some soft skills in order to master his profession. His core competence should be the communication. He needs to talk to developers, to management, to customers, to competitors, and to marketing. He needs to be able to explain things on different abstraction levels. He should be able to talk tech as well as he needs to be able to talk business but he also needs to listen. He needs to convince with awesome presentations and visionary stories. He needs to create confidence and he has to establish enough authority that even the CEO because of the PM’s expertise accepts a “no” about a product change.

A product manager must be a team-player, he will neither be able to build a product by himself nor will he be able to identify all requirements without any input.

He needs to be able to structure and prioritize. There will always be more work on his desk than he is able to handle. Often he will be a negotiator between different stakeholders of the product. He needs to decide which requests to prioritize, which to postpone and which to decline. Especially in the later case his previously mentioned communication skill with a dash of empathy are of high value. 

If you are going to hire a new product manager, try to keep these three columns in your head. Each of it  helps to master different challenges. Analyse the requirements of your company and which role the PM should really fulfil, but please don't degrade him to a pure scrum master. 

Read More

Product vs. Tech

Surprisingly often people are asking me: „Does it make sense to separate tech and product into different departments?“ For me that sounds a little bit like “Does it make sense to separate judiciary from executive?” Although I don’t have the format of a Montesquieu I want to share my thoughts about it.

Tech – The Executive

The task of a software engineer is to write awesome software. Ok, that’s maybe a little bit too generic. He designs an architecture that meets the requirements of the product. He decides about technologies and languages. He writes tests, automates processes, specifies APIs and tweaks around with protocols. He collects badges on stackoverflow, has more followers on github than on twitter and he contributes to a couple of open source projects. Watching him sitting in front of his screen(s!) gives you the impression he might suffer from ADHD because you neither understand what he is doing nor you get a glimpse of an idea how he is doing it because lots of windows and other weird things open, close and switch although he never touches his mouse.

Being a (good) software guy means being passionate about the things you do. Not being able to solve a problem will keep him awake and defocused the whole night.

Product – The Judiciary

The product manager is the guy everybody hates and wants to be friend with. His task is to understand the strategy of the company, the requirements of the market, the current needs of the different departments and he is able to predict the future. He morphs all this into a beautiful product and makes the company and the customers happy and future-proof. That sounds easy but actually he is in the middle of a couple of millstones. Instead of being a grain he needs to be a diamond resisting all the pressures coming from everywhere. He loves to communicate with all the stakeholders (customers, management, tech, operations, sales). He is tightly connected with marketing and he has no problem with saying “no”. He can perfectly balance operational and strategic goals. Like a gardener he cultivates his products and let them grow into big trees or cut them with all of their roots if he recognizes some illnesses that cannot be cured. He understands tech good enough to translate his ideas into blueprints that can be used by the software engineers to convert those into real products.

Separation of Powers

At a first glance, it looks like mixing tech and product would smoothen the product development process and reducing the communication overhead. But putting the tech department in charge of developing the product is the same as putting the fox in charge of the henhouse. Tech needs to be a stakeholder of product. The desire of doing a major rework, switching to a new cutting-edge data base technology, or enabling shortcuts for the GUI needs to be weighted out against timelines, market pressure and customer needs. The software engineers wants to bring the underlying technology to perfection. The product managers need to decide how much perfection can be afforded!

A software engineer is not able to do his best job if he is responsible for product. A product manager will not fight hard enough to push the technology to its best.  If you start a company you should separate these departments right from the beginning in order to balance quality and time-to-market. It gives you a good chance of doing the right things and doing the things right at the same time.

Read More