Allectus - Agile Product Management

The Non-Technical Product Person's* Survival Kit

Monday 27th February 2017

Being a humanities graduate in charge of digital goings-on can be challenging - but then, didn't they say learning keeps you young?

*Product Person = They that do products, i.e. Managers, Owners, Analysts, Directors, Evangelists and Wizards.

Even if you followed your heart and your batty aunt Sally's advice and learned or studied whatever you liked with blatant disregard for your professional future, life can still play pranks on you and thrust you into a very technological product role.

This means that:

• You will have to make decisions associated with an alien world peopled by strange beings with entertaining personalities who pair-program and expect you to prioritise their workload.

• You will have to explain to impatient stakeholders, in some byzantine detail, why a certain thing just cannot be done by tomorrow afternoon.

• You will have to reckon with other teams who might be blithely unaware of the impact their work might have on yours.

There is no doubt that a truly great Product Person should strive not only to gain product and domain knowledge but a thorough understanding of what's happening in their immediate and wider technological environment.

Don't be satisfied with flying blind. You want to present your work with confidence, talk to teams in a language they understand and inspire trust in your decisions.

Here's what you need to know at the very least

• Your environment's basic components and how they interact: data stores, applications, web services, frameworks, data flows, inputs and outputs.

• Your team's 'building site' in this basic structure: new product or major upgrade, components up for replacement etc.

• What other teams are working on and how their work or deadlines impact your product.

How your team works: programming languages, technical challenges, methods, preferred modes of delivery.

Here's how to build knowledge

• Schedule meetings with architects and developers as early as feasible and ask them to draw you a diagram or elaborate on documentation you might find internally. (Do this at least three times with three different people - you'll be amazed at what you'll learn.)

• In team meetings, raise your hand consistently if you don't understand something. Do this with pride and as confidently as you can. Yes, the odd person might roll their eyes. So what. You bet they don't know a thing about Karl Rahner's writings on the economic and immanent Trinity.

• Keep a terminology list. Each time you see a tech term you're unfamiliar with, write it down and look it up. Review the whole list occasionally. Connections will emerge over time. Find yourself a sympathetic hipster for further explanations.

• Ask developers about how they implement stories, what happens behind the scenes and about tech debt.

• Schedule meetings with Product Person colleagues and invite them to explain their products to you. If there is a knowledge gap you share, ask an expert to schedule a session with your team so all benefit.

• Sign up to a great self-study website and do basic courses on the subject area in question. Pluralsight is awesome and inexpensive, as is Treehouse. There are tons of others.

If you apply yourself to the above with some consistency, you will soon find that everything falls into place, knowledge gaps disappear and your confidence soars.