Don’t allow your CMS or technology to define your product

By
Kieran

All too often we sit through discussions with colleagues on how to solve for a product need through technology and we are underwhelmed with the limited options for consideration. They are typically too few or too many in number, too brief or too detailed in their justification, too qualitative or too cold and analytical in their assessment.

Key points:

  • It is your business so get involved.
  • Work together to work smart, not hard.
  • Make a persuasive argument with just enough evidence to back it up.
  • Don’t be afraid to provide some direction and have some constraints.

All too often we sit through discussions with colleagues on how to solve for a product need through technology and we are underwhelmed with the limited options for consideration. They are typically too few or too many in number, too brief or too detailed in their justification, too qualitative or too cold and analytical in their assessment.

A good product manager knows that it is not just down to the solution architect to put forward a case for technology direction. They roll up their sleeves and bring their experience to the table. They have results oriented, customer first thinking to drive the right outcomes.

A solid grasp of the problem being solved is important

Look, I get it. Wading into the technical solution design can be daunting for many product managers. You can run the risk of stepping on toes. You can alienate your team mates in the technical roles. But this doesn’t have to be the case.

You work to bring the broader team along the journey for your product roadmap, you need to participate in how that is brought to life. If you own the direction for the product and have long term needs that only you fully appreciate, how could the solution architect take these factors into consideration in a vacuum.

You know that you need to sell a vision of the product. And by doing that you inform the team that needs to work on bringing it to life. The clearer these needs, the better informed the team is to make the best recommendations and decisions.

Doing all this by chucking a document over the fence isn’t very ‘Agile’ though is it… So document it the way that works best for you and your audience but for the love of all that is holy, work together collaboratively on this piece and you will avoid many pitfalls.

Most likely, your skills will be higher when it comes to presenting a persuasive, considered argument in an aesthetically pleasing manner so put those skills to good use. By owning the form of the output, you can help craft the message and ensure that multiple paths are considered beyond the pet path that perhaps the architect wants to leverage initially.

Don’t fall into the trap of analysis paralysis

Whilst ensuring multiple paths are evaluated, and there are many techniques that can help you, you need to avoid wasting too much time on this. Consulting firms use techniques like Minto Pyramids and MECE to frame up arguments and break down problems for analysis. Research these techniques and they will help you throughout your career.

By developing assessment frameworks you can have some analytical basis for your recommendations. By framing the story through the lens of hypotheses and supporting evidence you can convey the message in a persuasive manner that will resonate with your audience.

You need to constantly evaluate the work through the lens of whether it will satisfy the audience needs. Make sure it is compelling, but also detailed enough to stand up to scrutiny of the board that reviews your submission. Make sure it provides enough direction to the downstream team without locking you into a detail level decision that you haven’t got the evidence to support and want to defer to the execution team.

Keep your audience in mind

A robust technical solution evaluation can have multiple audiences. Primarily you are looking to make a set of recommendations with adequate justification. This aspect is for the decision making body (e.g. investment committee, executive management, etc.). Additionally you are looking to provide design direction to the team downstream. This is who will be breaking it down into features/stories and executing the work.

Whilst Agile favours empowering the team through letting them make decisions, you still need to manage your business. So providing clear direction and an appropriate technical design is key. As is making sure it is in line with the architectural and commercial vision for the business.

Management must set direction and direction is critical for teams to be able to make good decisions.

Whilst this can be a constraint, constraints can be very useful. Research tells us that embracing constraints can actually aid innovation. That when no constraints are placed on teams they follow the path of least resistance.

We acknowledge the Traditional Owners of country throughout Australia and recognise their continuing connection to land, waters and culture. We pay our respects to their Elders past, present and emerging.
Let's talk about your product.