profile pic

Precise Asteroid

Welcome to Amir's Blog 👋



First Part: The People

Team Empowerment and Accountability

The term product team is important. Engineers usually don't think about themselves as part of the product team. They should.

✅ start calling your teams Product Teams

Product teams are there to solve hard problems for the business. They are given clear objectives, and they own delivering on those objectives.

They are empowered to figure out the best way to meet those objectives, and they are accountable for the results

The team should last for a long time. At least as long as there is a problem with big potential to solve. The team should not be assembled for a specific project.

PM role

  • You might have a data analyst to help you with this, but the analysis of the data and understanding you get of your customer is not something you can delegate.
  • The PM usually starts her day with 1 1/2 hour analysis of what has happened in the last 24 hrs. AB tests results, etc.

GPM role

  • IC but also coaching PMs
  • Good fit for ppl who have not yet decided if they want to be IC or VP
  • The IC path for PM ends with Principle PM
  • The GPM usually leads a group that works very closely together

Second Part: The Product

The problem with road maps

Most items will not work as expected for the following reasons:

  • lack of value - it does not provide user with the value they had hoped for
  • Lack of usability - users find it hard to use
  • Lack of feasibility- we can't build it or afford supporting it
  • Even the ones that do pass the 👆barriers will require few iterations

Strong product teams understand the nature of the beast and do not blame the idea's originator. But rather work to resolve these risks.

We should prototype the ideas with users, customers, engineers and business stakeholder in hours and days and not weeks and months

The Alternative to roadmaps

The reason management is after roadmaps is that they are interested with ensuring two main things:

  • The team priorities are based on business values
  • Meeting real dead lines

Any alternative process should accommodate for these legit asks.

But first the team would need to be familiar with:

  • Strategy and vision so they understand how everything works together
  • Understand business objectives of each product team

For example reduce onboarding time to 3 min instead of 20. But they also need to understand why that would help the business

Business should provide each team with the objective they should solve. The team should then create an outcome-based-roadmap, where each item is assigned with the outcome it is supposed to achieve.

  • The team is much more motivated as they are the ones coming up with the solutions trying to achieve the objective
  • The team is not “off the hook” by delivering the feature. They need to deliver the outcome
  • It doesn’t matter who brought up the idea anymore, b/c the first idea will not work anyways.

Then deadlines are to be delivered only for the items that really need these. Not every item.

This makes me think that one should care even less about balancing quarterly capacity vs the work needed. instead one should make sure the items other teams depend on are delivered on time, but other than that, just work top to buttom based on priorities.

Product Evangelism One can evangelize the product through the following methods:

  1. Build a prototype
  2. Share the customer pain with the product team
  3. Share vision
  4. Be generous with credit and take responsibility with failures
  5. Be excited and show enthusiasm
  6. Do demos and do them well
  7. Show that you are learning, especially from failures
  8. Spend time with your team. Especially when located remotely.

Third Part: Product Discovery

  • Get you ideas in front of real users and customer early and often
  • Learn fast but release with confidence

Opportunity Assessment Technique

For most product work, from optimization to small features

  • Business Objective - the problem you were assigned with solving: for example reduce the time wasted on pickup
  • Key Metric - how would you know if you succeeded: for example same 20 sec on average
  • Customer Problem - what problem would it solve for our customer. For example it would increase the paid minutes for drivers hence their earnings
  • Target market - don’t focus on all. Focusing on a niche would help solving specific problems. For example a geography, a city or type of drivers.

Customer Letter

For bigger features. Amazon is very famous for its backward approach where one starts with a PR. This is a variation of that technique where we start by writing an imaginary letter from an happy customer addresses to the CEO, explaining why he was so happy with the new feature and how it helped him, followed by an email from the CEO to the product team.

Discovery Sprint Techniques

Do that when:

  • The team is running too slow and you want to reboot
  • When the team is just learning to do product discovery
  • When the team has something big and challenging to tackle

📚 Sprint: How to solve big problem and test

📄 Good Product Manager, Bad Product Manager

Made by Amir 💚