Product Strategy

Implement product roadmaps

Roadmaps are representations of strategy, used to bring:

  • Control to development efforts

  • Clarity to relevant stakeholders.

In implementation, they’re a manually curated list of tickets from a Strategy backlog, possibly also including ones from Projects/Product backlogs.

A way to implement that would be to tag tickets with Roadmap, then querying for these, and presenting the results as a table or Gantt chart.

Prioritizing development goals is about human judgement

Strategically prioritizing product development goals is to navigate and blend the priorities (pain) of different stakeholders, such as:

  • End users who are pained by small issues that are apparent in the UI/UX.

  • Admin users who are pained by missing functionality that end users don’t care about.

  • Development engineers who want to change the architecture to accelerate future development.

  • Marketing people who want to spend time and effort on consistent branding.

Models like the RICE (Reach Impact Confidence Effort) scoring model attempt to turn judgement into turn-the-handle mechanism, which, naturally, incompetent people cling to as a silver bullet, and without critically understanding its inaccuracies and inadequacies (bias, lack of weighting, missing factors like technical flaws, and more).

User feedback systems, like UserVoice, help to gather customer insights but user voting is a flawed mechanism.

  • If highly-voted-for requests are weighted to be presented higher up in the order, then there’s a spiralling tunnel vision effect where getting exposure to new requests is increasingly difficult over time. This effect is amplified if bots routinely clear out requests with low numbers of votes. One can often see the contributor complaints that a good idea is submitted repeatedly but killed due to lack of votes.

  • 'Popular' doesn’t necessarily equate to 'valuable', and value can be subjective. End users might want the shiny functionality, but if the admin doesn’t get the boring functionality then it’ll all end in tears.

  • Singular voices that produce valuable feedback can get drowned out by the crowd. Are the contributions of a large crowd always better than a few people with deep expertise? How about the crowds at Nuremberg?

The reality is that in the end, good product strategy comes down to human judgement i.e.,

  • Expertise.

  • Eating your own cooking.

  • Having good 'taste'.

Empathy with stakeholders is key

The ability to put yourself in the shoes of a stakeholder - whether a customer, a user, the company leadership, your engineers, your customer support department - is key to allocating your organization’s finite development and operational capacity.

Problems occur particularly when people with responsibility for product leadership are disconnected from the experience of some stakeholders. For example:

  • Not having the domain expertise of the customers/users.

  • Not understanding the negative impact of legacy technical issues on development efficiency.

There are lots of techniques that can help, such as:

  • Kicking the tyres of the product yourself

  • Shadowing

  • Authoring personas

but fundamentally, the only techniques that really help are:

  • Learning (by conversation, doing, studying)

  • Imagination

Customer comes first

Products and services are to generate voluntary exchanges of value for someone’s money.

Even non-commercial efforts require funding. If you don’t provide the value, someone else could (and probably will).

Thus, as much as software engineers often hate it, the customer (business) needs to take priority over things they want to do to ease their pain, say, improving the architectural quality. Sometimes you have to explain this, and drive exposure of engineers to the business side of things (by secondment or collaboration with other departments).

There’s a limit to this and, as in all things product, it’s a matter of judgement as to when to divert development efforts to prioritize one stakeholder over another.

Be pragmatic

At the highest generalization of product development strategy, use this structure:

  1. Make it work.

  2. Make it work well.

  3. Release it.

  4. Make it work better.

  5. Make it fancy.

The frighteningly common occurrences of mixing up the order or skipping entire steps, resulting in:

  • Poor user/customer experience.

  • Rapidly escalating total cost of development, not least due to substantial rework.

Use date-based/CalVer versioning

Semantic version schemes attempt to categorize the changes made to the product between versions. The problem is the ambiguity that sometimes arises - depending on the nature of the product - as to how to categorize the change e.g. when a change is 'new' versus something existing that’s been 'improved'.

Semantics is the meaning of words, and sometimes it’s not so clear cut… and a waste of mental effort to think about.

Save yourself the grief and use a date-based or CalVer versioning scheme and don’t 'hard code' the semantics in the versioning scheme.

Instead, you could introduce ('soft code') the categories in product release notes if you wanted to.

Build a friction-free user feedback mechanism

Your best and most cost-efficient QAs are the users of your products and services.

Some percentage of your user base will have the understanding and conscientiousness/self-interest to provide valuable feedback that will result in better products and services for them. To get the feedback, you’ll need to build a mechanism e.g., a structured form.

However, even the most enthusiastic reporters will be put off if the mechanism has sufficient friction, and it doesn’t take much. Therefore, it ideally is:

  • Immediately accessible e.g. in-app

  • Minimally burdensome e.g. pre-filling contextual information, single-click submission of logs.