Paolo Belcastro

Cynical Optimist

product management

akumal ardes austria berlin chicago costa rica CRM distributed dubrovnik fmw focus france h iceland japan las vegas lisbon london mediterranean montreal nashville new york city office orlando palermo paris personal-productivity personal growth photomattchallenge PRM product product management review sabbatical-2017 sabbatical-2023 san francisco second-brain ship30for30 shotoniphone time-management tokyo v vienna whistler work

  • What does it mean to be a Product Lead?

    • Customers have needs.
    • The Business has goals.
    • Hardware & Software Infrastructure requires investment.

    The Product lives at the core of this Venn diagram.

    The Product Lead “expands the middle.”

  • This is the simplest and most effective framework to help Product Managers triage large numbers of ideas

    Estimated reading time: 2 minutes

    The 2×2 Matrix, an unsung hero.

    Imagine a long list of ideas, limited time, and people.

    Consider two uncorrelated dimensions across which you can compare these ideas. Pick what makes more sense to you. I generally use Effort and Impact. Rate each idea on each dimension with only two options: high & low. You’ll find the exercise surprisingly quick and easy.

    Soon you’ll have sorted your long list of ideas into four buckets:

    • Low effort / High impact → Low hanging fruit
    • High effort / High Impact → Important ideas
    • Low effort / Low impact → Nice to have
    • High effort / Low impact → Trash

    Comparing vs. Measuring

    It’s quick and easy because humans are good at comparing things.

    Give two objects to someone, then ask them which one is heavier, and they’ll answer without hesitation, even with a small difference. However, ask them how heavy each object is precisely, and most people won’t answer correctly.

    Our brain is not very good at measuring things.

    Complex frameworks don’t work at scale.

    Forget RICE, BRICE, and all the others to triage long lists.

    Measuring requires time and effort. It is not sustainable to do so for a large number of ideas. If done quickly, it only becomes a hand-wavy exercise to cover one’s ass in case things go wrong.

    Don’t run away from responsibilities.

    The 2×2 Matrix can save your life too.

    Another popular 2×2 Matrix is the Eisenhower Method.

    It uses Urgency as one axis and Importance as the other. You then rate each task on your to-do list as urgent or not, important or not.

    As a result, you’ll get these four buckets:

    • Urgent / Important → Do it yourself, now.
    • Not urgent / Important → Schedule it for later.
    • Urgent / Not important → Delegate.
    • Not Urgent / Not Important → Don’t do it.

    There are many other examples. The 2×2 Matrix is a life-saver!

  • One developer myth that you must debunk to increase productivity and impact as a Product Lead

    Estimated reading time: 2 minutes

    “It will be ready when it’s ready.“

    If you work in the software industry, I am sure you have heard some variations of this statement. It was probably a close neighbor to a rant about how deadlines kill the productivity of dev teams. I wouldn’t be surprised if someone threw the word “arbitrary” in there somewhere to add some drama.

    Let me tell you why this is wrong.

    Software can’t be “ready” before it’s shipped.

    One of the signs of a healthy codebase is an active issue tracker. It should list many issues and enhancements, host discussions about these, be consistently triaged, and prioritized.

    The keyword here is “prioritized.”

    Without prioritization, an issue tracker only becomes an overwhelming idea and bug report graveyard. In random order, with no notion of effort or impact, developers can’t see the end of it, as new issues are opened faster than they can be closed. Real people using the software are the best tool you have at your disposal to prioritize that list.

    Shipping is the best prioritization tool at your disposal.

    You don’t know the answers beforehand.

    Heck, most often, you won’t even know the questions. If you do not break down your work into small size chunks, which you can regularly ship to test your hypotheses and (in)validate your assumptions, you’ll be building a product that nobody out there wants. You are trying to solve an actual problem real people have. Listen to them.

    You can’t listen to them if you don’t ship anything.

    You are not working alone.

    Last but not least, you must understand that your flexibility ends where the flexibility of others begins. Any medium-sized project requires the collaboration of multiple people across teams and roles. They have other commitments, and their ability to plan is the best guarantee of the overall success of your enterprise.

    Respect your teammates.

  • One roadmap format that gets stuff done for cross-team software product leads

    Estimated reading time: 2 minutes

    A few years ago, when I started having enough teams to lead that I couldn’t fit everything on a post-it note anymore, I discovered the work of Janna Bastow (@simplybastow).

    What seems an obvious concept today was quite abstract back then: get rid of Gantt charts and start thinking about buckets: Now, Next, Later.

    For more details on Janna’s vision, I suggest checking this thread.

    Now/Next/Later

    One of the core objectives of your roadmap is that it should never lie.

    It will change. Changing is the only way a roadmap never lies because there is simply no way you got it right from the start.

    Now contains those items that are happening. People are working on these right now. Accidents may still occur but are less frequent.

    Next is a prioritized list of projects you are confident will move to Now as soon as you have the capacity. Of course, priorities may shift, and Next can change. It often will.

    Later is a vision of the future with today’s information. It constantly evolves based on new learnings. It’s a visualization of your strategy, not a promise.

    My pragmatic approach

    The Now/Next/Later roadmap works well as a tool to figure out what your future product should look like and how to get there from here.

    I’ll be candid, though, “it will be ready when it’s ready” isn’t practical when working across teams and disciplines, and, in my book, a pretty big red flag (we’ll discuss why tomorrow).

    So my concession to timelines is that once projects move to Now and teams dive into them, I ask them to estimate their duration. I also require them to update that information systematically every time an event delays their progress when it happens. With this approach, our roadmaps never lie, but we have a tool that rallies all stakeholders and enables cross-team collaboration.

  • Three quotes by Richard Feynman for new Product Managers to start with the right foot

    Richard Feynman is probably the most quoted Physicist nowadays, at least on Twitter.

    I admire the scientist he was and his views on education and learning.

    Over time I noticed that some of his principles fit exceptionally well with the foundation of Product Leadership in the software industry.

    So, for you, the new Product Manager wondering what to do now that you got the coveted title, here are three of his quotes translated into Product parlance.

    To develop working ideas efficiently, I try to fail as fast as I can.

    Iterate fast, experiment often, and learn, always.

    Learnings will compound, and decisions will improve. Building a software product isn’t about being systematically right. Where would the fun be?

    Over time, you’ll become better at evaluating costs and impact, better at investing time and effort, and eventually increase the returns on those investments.

    I wonder why. I wonder why.
    I wonder why I wonder.
    I wonder why I wonder why
    I wonder why I wonder!

    Ask questions, and when you get answers, ask more questions to your users, your team, peers, boss, and stakeholders.

    Make sure you perfectly understand the needs, aspirations, constraints, dependencies, and goals of everyone involved.

    And explain! You’ll spend a lot of time explaining the whys to keep everyone aligned once you have understood them.

    The first principle is that you must not fool yourself and you are the easiest person to fool.

    Maybe the hardest thing to do.

    It is so easy to start thinking that you have all the answers, that you MUST have them, and that is what the role is about.

    It’s not. When data or experiences disprove your hypothesis, they aren’t telling you that you were wrong. Instead, they are providing you with valuable information. Therefore, you must let them tell you the truth, not what you want to hear.

  • Product Management 101: you don’t make it; you make it happen

    Estimated reading time: 2 minutes

    You are the Product Lead. You are responsible for the product.

    In the words of Peter Drucker:

    Authority without responsibility is illegitimate, but so is responsibility without authority. Both lead to tyranny.

    So, ideally, you have both authority and responsibility. You are held accountable for the outcomes that your product generates and given the final word on the decisions that affect them.

    I have explained why the Product Lead role is a balancing act. Add that to the notions of accountability and responsibility, and we can start sketching a slightly more accurate vision of the position.

    Entering the danger zone

    You are equipped with these considerations and a substantial amount of stress. You must prove your worth. You love your product. You love your job. You want to succeed.

    Around you, a team of excellent professionals, and you trust them to execute the tasks you give them with a high standard of quality.

    They must execute your master plan, right?

    But they can’t possibly grasp the full extent of what you are trying to accomplish, right? Only you live and breathe through this product, right? Any failure will be your fault, right? Or your success if it works, right? They must execute your master plan, right?

    WRONG!

    Attempting to control everything and dictate instructions is the wrong approach and a recipe for disaster.

    Leaving the danger zone

    You must remember that every person in your team cares about your product as much as you and is more skilled than you in their specific role. They all know aspects of the business, the customer journey, and the infrastructure you ignore.

    They are your best source of ideas. Your role isn’t about telling them what to do. It is about setting clear goals and key results, coordinating, removing obstacles, and helping your team be the best version of themselves.

    You do not make the product; you make it happen.

  • Product Management 101: Expanding the Middle

    Estimated reading time: 2 minutes

    Imagine a Venn diagram.

    Three circles, overlapping partially with each other.

    The first represents your customers.

    They have lives, they have dreams, they have duties, and goals, and problems. So you set on a path to help them solve or achieve some of those. They are the reason why your product exists, why you are dedicating most of your energy, waking hours, and attention to it.

    They may be only a handful, or they may be millions. They most likely don’t know what they want or need, but trust them to tell you loud and clear what they do not. So listen to them carefully —even their silence.

    The second represents your company.

    From founders to leadership, investors to teammates, all embarked on the same journey. It’s a business. It must cover all its operating costs. It needs to pay staff, grow, and ultimately generate profits to invest in the future.

    Hopefully, goals are clearly defined and commitments explicit and reciprocal. At times you may have to figure out part of that on your own, but ultimately you must meet or redefine them.

    The third represents your infrastructure.

    Your software stack, your network, your data centers, the shiny new code using the latest JS framework, the bits you acquired along the way, and the legacy codebase that has been faithfully serving your product for 15 years.

    It enables you to build your product and dictates its harshest limits. It represents a continuous balancing act between execution speed, product quality, taking on new technical debt, or paying it back.

    In the middle, they overlap.

    Right there in the center, it’s you, the Product Owner. Your role is to find the center of gravity of the pulling forces represented by the three circles above, then expand the center space that is their intersection.