Mark Johnson

    PM frameworks

    Tuesday 30th April, 2019 - 5 min read

    This post covers the tools, concepts, principles and frameworks which I’ve come across that have helped me to become a better PM.


    5 Why’s

    Ask ‘Why’ five times to get to the root cause of a given problem. Used by Japanese car manufacturers, it seems to be particularly useful for live site issues with support and maintenance, but I’ve also used it to understand users deeper desires

    Learn about the five whys technique


    A framework used during product design to help clarify the situation, identify users, identify problems and find potential solutions.

    Circles method product design framework


    Continual feedback loops

    We’re prety hopeless as individuals. We have our flaws and biases, we misinterpret and we overvalue our own work. Getting continual feedback from customers, colleagues and others on ideas, designs and more helps us to continue to course correct and deliver better end results. But don’t go to the other extreme; design by committee is no better than an isolated designer.


    For any product/process, ask what is the minimal viable product I can deliver. Helps to gather early feedback to inform future decisions. Very related to continual feedback loops.

    Distributed over centralised

    Try to remove yourself from decision making where possible. Systems function best when decisions are made at the edge. Provide the context and give individuals responsibility to make decisions without you.


    Everything that’s important should be opt-out. Whether it’s saving money, exercising, eating right, sending status mails or anything else. Try to built a system so that the right thing happens by default. For example, setting up a standing order to transfer 10% of your salary into an investments account.

    Difficulty informs design

    If you’re having to squeeze designs into a modal or developers are saying that implementing a feature will take months, listen to this signal - it’s telling you that the design isn’t right, it’s complex. Good design should result in clear UX and minimal coding. Re-state the problem until you can find a simple solution.


    We can only handle so much complexity; create checklists for repeated processes. Checklists for running user interviews, for managing the project lifecycle of features, for assessing designs.

    Lazy evaluation

    You shouldn’t specify everything up front. Don’t plan for 6 months out. Don’t design architecture for a million users if you’re at a thousand users. By the time you get there things have probably changed enough that you need to re-assess your plans.

    Working backwards

    At Amazon they write the press release before any work begins to help them ensure the feature provides compelling value for the end-user. Start with the customer needs and work backwards to meet them.

    Enjoyed this post? ❤️

    Subscribe by email or RSS.