Specialist jargon often baffles the uninitiated an impacts all professions: product management is no exception. I am going to burst some of the most cryptic jargon of day-to-day product management so that you can more quickly get to the bottom of what people are really talking about.
Stakeholder a.k.a. Nuisance no. 1
A stakeholder is someone who has an interest in what you are doing, which 99 out of 100 times means they are going to be a pain. Managers force stakeholder strategy on their product people, because they are scared you will go rogue and create a 5-legged table with a curved top that nobody will use. To avoid being assigned some jerks as stakeholders, be proactive and present a stakeholder list before one gets assigned to you. Mindblowing!
Product Vision a.k.a. Slides, docs and too many talks
Developers, managers, sales people and even janitors will ask you for your product vision, as if it came to you as a revelation on the foam of your morning flat white. There are two documents you need to have always ready and in tip top shape: a Roadmap and a Vision. Don’t hold on to them, give them out as if it was candy. If you don’t have a vision yet, read up 5 Steps to develop a shared product vision. If you don’t have a roadmap… why are you even reading this blogpost?
Technical Debt a.k.a. The house is falling apart
Sooner or later you will hear the phrase: ‘We cannot develop this new functionality now, we need to refactor. There is just too much technical debt’. This is not an excuse, but a desperate attempt to tell you that the code is so crappy people are afraid to touch it. Refuse at all costs the proposal of a sprint of refactoring: it will open a time-space singularity that is going to suck in your career. Ask what is the smallest thing that can be fixed each sprint and keep going until the house is not shaky anymore.
Acceptance Criteria a.k.a. Harness the lawyer in you
Acceptance criteria are the key clauses that constitute the contract between you and your development team. At the start of the sprint it’s all roses, but when the sprint is over, developers quickly turn into a small army of cunning lawyers letting you know how ambiguous those acceptance criteria are and why they didn’t meet them. There is a lawyer in all of us and you need to let it loose when you write acceptance criteria: they should be clauses that leave no escape.
MVP a.k.a. Don’t build a UI just yet
A true minimum viable product is as rare as a unicorn, and if like me you work with a bunch of smart and ambitious developers — check out the survival guide to developer types — you will find that their idea of MVP is very different from the true definition. Use all tools of persuasion and stubborness to shift developers from creating a fancy UI into developping a terminal-only, super ugly application, that brings the minimal amount of value to the user.