Tools for building

Look for duct tape.

If someone is not actively creating poor solutions to solve a problem, they are probably not motivated to spend money. Where are people using 100 cell excel sheets, constantly complaining about or actually using duct tape? Those are the best problems to solve.

How do you know your idea is a good problem to solve?

Imagine a four leaf clover, with the following words on it. Try to turn each leaf green.

1. End user data

2. Customer data

3. Gut/perspective

4. Competitive knowledge

For example, when LinkedIn started to see hybrid work post covid, we experienced it (3), then we saw people searching for it (1), then we had customer trying to post hybrid jobs (2) and we saw competitors quickly standardizing on it (4). It was a no brainer.

Clearly some other items are harder to understand. When we at LinkedIn started to push for skill based hiring (alternatives to college degrees), we saw members wanting it and all had experiences of being passed over. But customers were not removing them from job descriptions, and few other companies were on it. We had to go out and talk to 100 customers and run a pilot to validate.

Even if you found a problem, depending on your scale, this might still not be the best problem to solve.

Sometimes you find a list of small problems around an area. For example, if you want to help better get a promotion at work, you might want them to know the jobs open, know the careers they can pursue, find people to meet in an organization, find mentors, etc. Where do you start?

1. Create a spreadsheet. List all your pain points in the first column

2. Add three more columns: how acute is the pain point, how frequent is the pain point, how many people are impacted by the pain point

3. In each row, mark if the pain low, medium or high in acuteness, frequency and people impacted.

4. Sort first by acuteness (willingness to pay), the frequency (lifetime value per user), then people impacted (TAM)

A product strategy requires five parts

1. A clear understanding of a problem statement (see above on how to validate) which includes a market size

2. A clear vision of a solution

3. A clear set of sequenced steps to get that vision (do you start by segment, how will you grow)

4. A list of the 5 most important things that need to be true to work and the 5 biggest risks

5. A clear metric and targets so you can measure success

I use the the 5 min brainstorm more than nearly any other managerial tool. It reframes a room's energy from problem to what's possible. But brainstorming is an art that is hard to get right.

Here's my system. For the example, imagine we're creating a new gummy bear flavor. Ask the:

1. Direct question: 'what flavor would you create next' (1 min). This gets all the things people have been thinking, instead of listening, out on paper.

2. Opposite question: 'what's the worst flavor we can create' (1 min). This highlights all the constraints.

3. Analogous question: 'what's a great ice cream flavor' (1 min) This shows people this problem is not unique and solvable.

4. Weird question 'what if we create a gummy bear for dogs' (1 min). This gets people excited about what's possible.

5. Spend a min discussing and suggesting team goes deeper on key ideas. This sets the tone to begin converging on solutions (1 min).

At some point you will start measuring success. This might be units sold, connections made, delight created.

1. Always look at the growth year over year. You can have a great day or a great week, a year helps average

2. Aim for at least 20% y/y growth. For whatever reason investors see that as a high growth business

3. If you are starting a new product or entering a new segment, make sure that SKU is growing 2x as fast as the core.

1. Great question askers are acutely aware that the time to answer a question far exceeds time to ask. It's an intentional management skill.

2. Great question askers only ask questions that will actually change a decision. They don't ask questions to look smart.

3. Not said, but observed, great question askers keep a question budget. They weigh in little, but when they do, you feel the impact.

4. Great question askers always phrase question as "seeking to understand". They do not ask questions as a negotiating tactic or test

5. People value great question askers as stronger leaders; we can all see how they improve an org's signal to noise.

Assign learning OKRs, the same way you assign product or business OKRs. Measure learning by requiring updates against the hypothesis each week.

Nothing makes people feel more valued than the gift of time. Some tactical ways to give time:

1. Be present (give your full time)

2. Be on time (don't waste someone's time)

3. Reach out when you think of someone (show they are getting your time)

4. Call/text people back quickly (show they are worth the time)

5. Remember what you discussed in the past (repeating wastes time)

One of the misconceptions in building things is that focus feels good.

Focus sounds positive, it brings connotations of meditation and being centered. But real focus at work feels awful. It's believing in all your heart something could potentially work, but having the discipline to not go after it. It's stopping things that are going 'well', and having to explain to people that doesn't mean they are meeting expectations. It's arguing with teammates who think this product is about to turn the corner.

Of course without focus, you can't spend the mindshare and resources to build the few things that matter right. Here are some tactical things that I've learned about focus:

1. Celebrate real focus. At LinkedIn, we send out deramp emails to celebrate things that we stop building. It's a small thing, but matters.

2. Don't penalize people in the review process if they spent time focusing. Call out great execution in shutting things down and make sure to give those people a choice of great roles after.

3. Don't ask a team to bring you a list of things to cut (at least for me, I always brought my manager things I didn't care about to pretend I was focusing). Instead, ask why we should keep working on x or y and use dates as a forcing function.

4. Mentally prepare to answer why you made the decision to cut something a 1000 times.

5. Let people have time to grieve the loss of a project. My freshman engineering professor had us design an amazing project and then tear it up. It was a lesson to show that hurts makers to see our work disappear - understand that emotion and know you want people who put their heart in the work on the team

It is much easier to ask a question than answer it. One take 5 seconds, the other takes days.

Here are some tips for how to best create the right signal to noise question ratio.

1. Ask only if you cannot answer first. Let the team know you tried to answer.

2. Ask only if it impacts your plans. There is no time for hypothetical questions

3. Ask only if it’s the most important question you could ask the person. if not, it’s a distraction

4. Ask only if there is a reasonable chance they know the answer. If not, phrase it as an action item and stack rank against other work

5. Keep a log of how much of a teams time is answering your questions

How to know if a process works

1. Simplicity

2. Clarity

3. Accountability

Explicitly create 1.5 hours of buffer everyday for ‘overflow’.

I used to dread the end of the day. All day long little things would add up and then I’d have to scramble to close them all. I’d come home exhausted and irritated - with little in the tank for my family.

The best advice I ever got was to explicitly create 1.5 hours of buffer everyday for ‘overflow’. It can be one block or several blocks, but that way at the end of the day you’re done. And you’re not taking home all the irritation

After years of experimentation, here is the meeting schedule I keep to build fast and together

1. 60 min weekly staff meeting for my leads. Agenda is talent and strategic updates

2. 45 mins weekly all PM and R&D leads operations. Agenda is to review key weekly metrics and ramps

3. 2, 60 min product deep dives weekly slots to review strategic products. Agenda of topics to cover are 75% decided by leads and 25% open slots.

4. 30 mins 1:1s b-weekly with my directs. Agenda set by them

5. 1 hour daily slot to meet my 24 “agreement” to any return any call from team or request for urgent 1:1

Let me know ways to improve too

There are two frameworks I use to evaluate a product leader

1. What/How: A product should be able to deliver results AND make those around them better

2. The Triangle. A great product team has three skiils: creativity, data and management genius. I’ve never found anyone good at all three, but someone should excel at least one. As you get more scenario, you should excel at two. Finally, the leaders should be smart enough to build a team that excels at all three.

See mindofhari.com/explorations/org-chart-diagrams

You should leave trusting the team about two things

1. Is the team approaching a problem correctly

2. Can the team execute

First 30 mins asking questions about the first one. Focus on having the team articulate & defend the pain point. Present alternatives and ensure the team is certain this is the problem

See if everyone on team saying same thing, see if team is prioritizing this, see if this is really a test or a must win. Listen for passion.

First, seek to understand.

Second, approach the problem trying to make the person’s idea successful (not analyze it.

Third, if there is something you want to say, make it clear if the recommendations is a:

1. Inform (not recommend)

2. Idea (recommend exploring)

3. Suggestion (explain why not)

4. Mandate (do it now)

What they have done.

Not title. Not what they said on social media. Not who they know

Mentor/product fit is rarely talked about, but so important. You only have so much time and you should spend it with the people who most need it.

1. Know what you specially offer. Be precise about what framework or skill you offer nobody else does.

2. Ensure the person is stuck on the problem you can help with. Mentorship works best when it is in the moment and not theoretical

3. Acknowledge that mentorship has a chemistry component. This should not lead to bias, but you should be honest if the person and you click.

Instill this process in your team

If there is a disagreement:

1. After 3 emails, always meet live

2. After 30 mins, always ask for a tie break. Spend the next 15 mins writing a document with which single breaks the tie and each person’s opinion. Email the person

3. After 5 days, the tie breaker must reply with an answer.

4. Disagree and commit

Good product people are good storytellers. Storytellers see trends. Trends imply extrapolation.

Where this goes wrong is unintentional exaggeration. How do you not do this?

1. Do not use these words: Many, always, never, going well, going poorly

2. Share absolute numbers and not percentages. (going from 10 to 100 users way less impressive as growing 10x)

3. Never communicate that something is exceptional in a weekly report. Nothing on a weekly timeline is exceptional

You have to care about everything in the product. You have to care about each piece and find the energy to make it all fit together.