Being a product manager: doing the thing right… but also doing the right thing
After a few years with positions of Product Owner / Product Manager in agile environments, a recent PM certification I passed made me realize how much being a PM means not only designing an IT solution right [doing the thing right] but also resolving the right problem for the user [doing the right thing].
On the one hand, since I’ve been a PM, I mainly focused my efforts on “doing the thing right”. Designing software is a hard job because it forces you to interact with the inherent complexity of computer systems.
Such systems are complex because they are among other things non-deterministic (a same action performed on two occurences can have different outcomes); no holistic vision; sum of component’s behavior doesn’t enable to predict the system’s behavior, etc.
Facing this, I’ve always thought about a PM’s mission to adapt its ways of working to deal optimally with these challenges. This is achieved through mainly two aspects :
1. Fostering technical excellence to achieve a sustainable and reliable product through advanced software design technics (TDD, BDD and DDD) jointly with DevOps and Automation.
2. Implementing lean and agile processes to enable efficient and short feedback loops that help achieving incremental objectives and delivering a flow of value to end-users.
On the other hand, since a few weeks I’ve had sort of a revelation that emphasized to me how much “doing the right thing” is equally important. One cannot stress enough how much you have to keep in mind as a PM creating a product that you are building it for someone, a user. This is as difficult as designing an efficient and sustainable solution as it makes you interact with the inherent complexity of human behavior.
It’s hard to define what makes human behavior complex. Some elements to be aware of in the context of product could be the following : users are easily biased towards a decision, asking them what they want might in itself influence them towards an answer ; even if they are unbiased, they might not be really aware of what’s best for them, of their “latent needs”. Something this quote wrongly attributed to Henry Ford synthezises quite well :
“If I had asked people what they wanted, they would have told me faster horses” Henry Ford (apocryph)
As a PM, it is then crucial to deal with this complexity in the whole lifecycle of product. To sum up how this takes place concretly, I like the definition of product design of Keenan Cummings
(i) Recognizing patterns of human behavior ;
(ii) discovering the motivations and impulses that drive those patterns ;
(iii) creating tools that improve or elevate the output of those behaviors.
This goes through two main fields of actions:
1. Do research to undertsand your users’ problems: focus on the problem first before to think about a solution; to understand your user, you need to observe them the most unbiasedly possible; and work iteratively with hypotheses statements you try to validate.
2. Conceive applications and make sure they solve the users’ problems: identify key features; design smart interfaces that guide users; take into account all the potential interactions of your user with them; build prototypes to validate your hypothesis then release a first version of your product and continuously adjust with feedbacks with the objective of maximizing product’s adoption.
Of course the point here is not to say that one of these two aspects is more important than the other: they are both equally crucial and necessary to build succesful products.
