The purpose of this article is to show some of the harsh realities we have to face, as opposed to the way it’s done in bigger companies. As a service company, we don’t require a product manager in our team (just yet). However, these are the people our company communicates with the most. I would like to say a few things about this role, as I feel there isn’t as much information on product management, as there is on some other, more popular professions in the IT industry.
Of course, there is theory, and then, there’s practice. I’ll start by giving a little theoretical background, and then I’ll go through a couple of the more peculiar cases, that occurred in my practice.
A product manager, ideally, is the person who knows the market, who knows the product well and the competition even better. It should be a person, who operates on the basis of strong knowledge and confidence. People who become product managers have different backgrounds. Most clients I work with, are part-time managers, who have initially either been businessmen in their respective fields, or CTOs, who were looking to enhance their team’s effectiveness through outsourcing. A good product manager defines the target with precision — the “whats”, rather than the “hows”; which means he won’t be going into technical details to the same extent, as would a project manager, for instance.
We don’t live in a perfect world, where everyone just does what they were supposed to. Rather, we do what we can, and, very rarely, what we want. Ex-developers get stuck on technologies they know best, or invest time investigating the ones they believe have a potential to take over the market in the near future. Sometimes, a small company, such as ours, has to deal with product managers, who spend their time developing a marketing strategy and raising funds. The best product managers I’ve met, however, are the ones who devote their time solely to the planning and then the double-checking of a product’s life cycle.
Here are a few types of product managers I have met so far, and there are pros and cons to working with any and either of them:
– has some coding experience or even a lot of it;
– may have had an IT company of his own;
– knows IT business well;
– works solo;
– doesn’t have any documentation or user story written down.
This is the first thing he lets you know. He shares his vision and tells you that you’ll “get there together”. This person needs some outside help. He doesn’t have a clear plan yet, of what exactly the product is going to be like, in which order are the features to be implemented. What he does have, is the urge to “show something” to his a potential investor or a client of his ASAP, in order to get the budget for the next sprint of development. His favourite phrase is “we’ll do more projects together once the investor buys in”. In reality, though, the chances of an American investor letting his company outsource a project is slim to none, especially taking into account the recent legislative implementations. A product manager, such as this, is convinced that his project is going to make him a fortune.
Unfortunately, another thing he doesn’t have, is the passion for the product itself. What he calls “agile methodology” in reality means “when I change my mind, you just follow the instructions, regardless of whether or not it’s technically expedient”. Later on, if you fail to adapt to the constant change of demands, which you probably will, he will consider the product’s failure to be your fault. On top of that, you will get tired of frequent making and dismissing of estimates, negotiating rates, what should, and what should not be billed for.
Disadvantages: you are going to find yourself in a position of an archaeologist, trying to make out an understanding the entire picture, by scraping for bits of information correspondence leftovers, and notes you took during the calls. You may well have to become a visionary, in order to satisfy the expectations because, I repeat, there is not likely to be any documentation, or even a user story written down.
Advantages: you are encouraged to come up with solutions and proposals, which in itself, is a certain level of freedom.
– is obsessed with quality;
– a lot of things “go without saying”;
– needs to keep in touch 24/7.
These guys can google for real. When they tell you “We’re not going to use ES6 here, because it isn’t supported by all the browsers”, it means they’ve just googled this, and there is absolutely no way to get a message across. There’s no way they would waste their time researching what “babel” is, and why we need to use one more extra technology.
If, by any chance, you were ignorant enough not to include any of the following into the estimate:
– the writing of automated tests;
– writing documentation;
– re-factoring a code, that has been written by someone else before you, so that it complies with the “new” code-style, that you are expected to use;
– comply with the customs of git-flow;
you will end up working day and night in order to meet the deadline because they “Go without saying”.
Advantages: a lot of communication experience can be gained from such projects.
Disadvantages: exhausting and time-consuming communication, where you have to justify, debate and battle over every technical decision you make.
A “Business Owner”:
– knows what he wants;
– will talk and listen to you in order to find the best possible solution;
– often with a degree of knowledge of the matter;
– well aware of the risks.
These people know exactly what they want. The chances are, the product will be an enhancement, perhaps an automation of some processes for his company. He’s not exactly an “IT person”, but he’s likely to have someone to guide him, without putting any external pressure. He’s not interested in impressing a potential investor in the near future, he just wants to make his customer’s experience better and, therefore, is not likely to try and cut corners, when it comes to agreeing on estimates, or acceptance criteria. However, this person will not tolerate delays.
Disadvantages: earning the trust of such a person is extremely difficult.
Advantages: by far, the more pleasant type of people to work with.
I guess if you are a small company something similar may have occurred to you as well and these cases sound familiar. How did you cope with each particular type ?