The Looking Glass: 7 Questions to Impress Your Boss

Beautiful status updates, navigating tightropes, building products, and meeting Taylor Swift

Hello readers!

This week’s tidbits:

1. 7 questions to impress your boss

2. Beautiful status updates

3. Navigating the tightropes of life

4. From the archives: Building Products

For paid subscribers:

1. Subscriber mailbag: How do you run a start-up and aspire for excellence as a mom?

2. My problem with coding

3. Meeting Taylor Swift

4. Craving novelty

You know the drill by now. I write some tidbits. I put the weirder, rawer ones behind the paid subscribers bar. Buy me the digital equivalent of a fancy monthly coffee by subscribing. Help me spread the word of that soon-to-be-archaic, pre-AI way of writing.

7 Questions to Impress Your Boss

Is your boss someone you respect? If yes, then…

Your boss is not impressed by you keeping your head down and simply doing what is asked.

Your boss wants nothing more than to see you excel and grow as a leader in your team.

The following questions can help you get there.

Yes, they may be hard to ask. Yes, the answers you get back may be humbling. And yes, asking is not enough—you will have to follow through.

But deep, honest conversation with your boss is the fastest way to grow in your career.

Trust me, your boss will thank you for it.

1. What do you think are the 3 biggest issues for our team right now? ⇒ Shows big-picture thinking and caring about the team’s success

2. My top 3 priorities are X, Y and Z — do you feel they’re the most impactful way for me to spend my time? ⇒ Shows desire to have impact and work on the most important things

3. I noticed X happened and I’m worried it might impact our team’s goal for Z — am I looking at this the right way? ⇒ Shows proactivity and transparency in identifying blockers

4. I’m thinking about trying X, Y, and Z to improve ABC. What do you think of those ideas? ⇒ Shows initiative in solving problems

5. What do you think my strengths and weaknesses are relative to others on our team? How can I double down on my strengths / mitigate my weaknesses? ⇒ Shows desire for growth

6. I am not as effective as I’d like to be on X — do you have any suggestions for how I can improve? ⇒ Shows self-awareness and openness for feedback

7. Can I share some feedback for you that might help you do X better? ⇒ Shows courage in speaking truth to power for the sake of the team.

Beautiful Status Updates

A highly efficient machine becomes so because of clear observability.

For teams, beautiful status updates provide that observability.

Everyone on a project team should know how to write a beautiful status update for their area of work. Not just PMs. And it should be done in <5 minutes.

While the specific details of what makes a beautiful status update changes for different sizes of teams, sizes of audiences, and nature of processes, the goal remains: 1) keep a group’s expectations in sync 2) speed up decisions 3) create clear accountability.

I’ll share my rules below for a beautiful daily status update designed for start-up teams operating remotely to be sent over Slack.

Don’t drop the ball

1. The most important thing is to consistently update daily without making others pull for it.

2. Pick a consistent time to do it every night, and stick to it. If some new information comes out in an hour or 2, you can always amend your status.

3. If you are sick, out for PTO, or otherwise can’t write the daily status, ask someone to cover for you for that period.

4. If you drop the ball, expect feedback on the ball drop.

Give ETAs for Launch and Milestones

1. The point of a status update is to keep everyone’s expectations aligned. Thus, lead with the Launch estimate on when the project will be shipped.

2. If it is hard to give an exact ship ETA (normal for early project stages when more research and scoping is needed), give a confidence % or an ETA date range. But always try to answer the ETA question.

3. Give the next milestone ETAs broken into discrete subtasks.

   1. These should be broken into the smallest work chunk, ideally those that can be completed daily.

4. List subtask owners next to their responsibilities

   1. This makes it easier for everyone to see who to ping if there are questions / follow-ups.

Communicate expectations in the headline

1. If things are on track, say “on track to launch <DATE>”

2. If things got delayed because of new information, say “Delayed 1 day; now expected to launch <DATE>”

3. Explain what was the new information in a bullet below

4. If there are issues that need to be resolved, make that known (see next point)

Communicate blockers in the headline

1. The job of a status update is to maximize decision-making speed and surface blockers or dependencies asap

2. If progress is blocked on a decision or some other team, put “BLOCKED” in the headline

3. Describe the blocker in a bullet and tag the folks who can unblock (ie, decision-makers, other team members, etc.) Suggest an immediate meeting if needed.

Tag aggressively whoever should see the update

1. Updates are useless unless they are read and adequately provide the observability and transparency needed to make decisions quickly.

2. It’s better to overtag than undertag.

3. If you are a status reader, and you feel overtagged and don’t think the updates are relevant to you, simply tell the poster that you don’t think you need to be tagged and you’ll check the channel when needed.

Anyone can be the designated status updater

1. It can be the pm, engineer, designer, sales person, data person. Anyone who is deeply involved in the project. But everyone (including this person) should know they are designated.

2. At the start of the project, nominate yourself or someone else on the team

3. Over time, some folks may enjoy it more than others; some may find it less taxing than others. That’s fine, but everyone should be able to write a beautiful status update. This is a skill that will serve you for the rest of your career.

Make it short and sweet

1. The longer it is, the less people will read all the whole thing.

2. With practice, a beautiful status update should take <5 minutes (though it may take longer in the beginning)

3. More than >20 minutes spent on a status update is far too long.

Navigating the tightropes of life

If I have a core philosophy, it is this: we are continually navigating the tightropes of life.

Some people will shout Avoid leaning left! which is not bad advice. After all, lean too far left, and you’ll definitely fall.

Other people will shout Avoid leaning right! which is also not bad advice. After all, lean too far right, and you’ll absolutely fall.

The extremes are obvious.

The art is in knowing which way you need to lean right now to keep in balance.

From the Archives: Building Products

How do you build great products? These are some of the lessons I’ve internalized over the years.

This list is not complete nor certain. If there were some perfect step-by-step instruction manual out there (Step 1: Start with inspiration. Step 2: ??? Step 3: Profit!), then we’d shell out good money for it and then pat ourselves on the back while watching amazing new products bloom around us like flowers fields in May.

The journey is 1% finished. Let’s keep trekking and learning.

On Framing

1. A product succeeds because it solves a problem for people. This sounds very basic, but it is the single most important thing to understand about building good products.

2. The first step in building something new is understanding what problem you want to solve, and for whom. This should be crystal clear before you start thinking about any solutions.

3. The second question you should ask yourself is “why is this particular problem worth solving?”

4. If the audience you are building for is narrowly defined (and one that you are a part of), then you may be able to rely on your intuition to guide your product decision-making. If not, then you should rely on research and data to inform your decisions.

5. If you are a start-up founder, your path will be easier if you go after a problem for a narrowly-defined audience, and then expand to broader audiences after you have some initial traction.

6. The problem you’re trying to solve should be easy to communicate in a sentence or two and resonate with someone from your target audience. If not, consider that a big red flag.

Execution

1. Good execution is about getting to believable conclusions in the shortest amount of time possible.

2. Bad execution is when you try something that fails and a) you can’t really draw lessons out of that failure that would apply to a future project (because you don’t know why it failed) or b) it took you a year to learn a particular lesson when a smarter path would have let you learn the same thing in 3 months.

3. What typically separates successful and unsuccessful teams is not whether they do things that fail (this is guaranteed), but how well they can consistently execute.

4. When exploring solutions for a particular problem, go broad before going deep. Brainstorm 10, 20, 50 solutions for the problem before getting into the mindset of picking a “winner”. The first 5 ideas will be the obvious ones. Creativity happens when you start to explore the 11th, 20th, or 50th idea.

5. If you’re presenting a product plan and someone asks “have you considered trying X instead?” and your answer is “No,” that is a red flag that your exploration process was not rigorous enough.

6. Use empirical evidence to help you narrow down the best idea(s) out of the ones you brainstormed. (For instance, pick the top N favorites from the team, design or prototype those out in higher fidelity, and put them in front of people to gauge their reactions).

7. Once you’ve figured out the particular solution you want to execute towards, frame it in terms of a hypothesis — what are you assuming will happen if you build this? (e.g. “The problem we want to solve is ensuring that every city resident knows what local events are going on every weekend. Our hypotheses is that we can reach X% of residents through an e-mail digest.”)

8. You should constantly be looking for ways to short-circuit vetting your hypothesis. Can you run your idea by some people on the street and see if it’s understandable? Can you run a survey targeted to your audience and gauge whether enough people are interested enough in the idea? Can you quickly build a version that gets you a clear conclusion, even if it’s not as complete as the vision you have in your head?

9. Once you have clear indication of positive signal on your hypothesis, don’t assume you need to rush to ship whatever you tested right away (as you may have taken some shortcuts to get a signal faster.) Instead, make a separate, intentional decision about what the bar is for full launch when it comes to polish and additional functionality. What’s acceptable to test and what’s acceptable to ship broadly should have different criteria.

10. If you’re embarking on a big project involving a lot of different changes, see if you can split up the changes into smaller, independently testable milestones. Don’t fall into the trap where you make five changes, get a bad result, and now have to figure out which change(s) were responsible.

11. Do a team post-mortem after every project, regardless of success or failure. What product lessons did you take away? What team lessons? What would you do differently in the future? Then, share these learnings with the whole company.

Measuring success

1. How you measure success is critical to the long-term results of your team because it’s the thing that people rally around. Make sure to give this exercise the proper time and attention (more, even, than you would give to thinking about “how should we do this?”).

2. Define what success metrics look like for your product before you launch. Otherwise, if you try to interpret results after they start coming in, confirmation bias will lead to a non-objective reading.

3. For each success metric, come up with a good counter metric that would convince you that you’re not simply plugging one hole with another. (For example, a common counter metric for measuring an increase in production is also measuring the quality of each thing produced.)

4. If an important metric moves unexpectedly, whether positively or negatively, your first question should be “why?” Don’t try to develop strategies to boost/counteract what’s going on before you fully understand the why.

5. Use the Crystal Ball technique to help you pick the right ways to measure success. Ask yourself “If I could know anything in the world about how people are using my product, what would I want to know to in order to tell me whether or not my product was successful?” (Typically the answer people come up with is not #of clicks on a button but something more abstract like How many people who used my product received value from it?) From that answer, work backwards to get to a measurable metric that best approximates what you’re trying to get at.

6. Your goals should always be set with the best information you currently have. If you were working towards a predefined goal and then discover new information that changes your understanding of the world, consider whether you should adjust your goals based on that new information.

7. If you work on a team where you don’t understand or agree with how the team measures success, bring that up right away. It’s better to hash through these things earlier rather than later given how fundamental this alignment is to productivity and good execution.

8. If you find yourself constantly getting into debates with your teammates about product direction, the root cause is probably a disagreement in the way you’re measuring success. See if you can articulate your concerns in the form of a new proposal to measure success.

9. If you are trying to figure out whether your product has product-market fit (versus trying to optimize or scale), you’re better off goaling on retention (how many people use your product and then love it enough to come back?) rather than on engagement or # of users.

Team Dynamics

1. Thinking in terms of your role (what’s expected of a designer? What’s expected of an engineer?) will cap your ability to have impact. Instead, think in terms of “What can I do that will most help my team be successful?”

2. Teams that fall in love with a problem have more successful outcomes than teams that fall in love with particular solutions. This is because knowing that a problem is worth solving continues to be motivating even when a team doesn’t come across the right solution on the first, second, or Nth try.

3. Always assume best intentions. I mean, at the end of the day, everyone wants the same thing — to build something great. You might be wrong some small % of the time, but you’ll still be saving yourself a great deal of unnecessary drama.

4. Understand what you’re uniquely good at, and what your teammates are uniquely good at. Then, divvy up team responsibilities in a way that acknowledges those strengths.

5. Good communication is the key to a healthy team. Every member of the team should feel like they can safely express their viewpoints, even if those views are contrarian. Diversity of opinions is how you get the best results. So don’t be afraid to express your view, don’t be afraid to repeat them if you’re not sure people heard or understood you fully, and strive to create that safety for others.