Author: Simon

Introducing More Good Work Talk

I’ve been working on something – and in the course of working on it, I realized that it was part of a bigger thing for me and the way I think about the Internet.

I have goals for 2025: I want to expand our vegetable garden. I want to place in a mountain bike race. I want to spend more time with my kids (while they want to spend time with me!)

Professionally I want to spend more time using and thinking about AI and its pros and cons. I also want to improve when it comes to impromptu communication: to be able to respond to a question that I’m not prepared for, quickly, concisely, and effectively.

(these aren’t all of my goals – not an exhaustive list!)

I figured I’d take a crack at both the AI piece and the speaking piece by leveraging ChatGPT to build a little web app. I was inspired by Vicky Zhao’s 1-2-3 framework, but wanted a simple, straightforward way to practice and then review, maybe making it a daily habit. Leveraging generative AI, my own (rusty!) HTML skills and a Github Page, and I got the pieces together enough to get something working.

More Good Work Talk – here it is!

But as I was doing this I had the experience of a few things: a classic two-wolves-inside-me scenario. One wolf was asking, “How will you monetize it? How will you know how many people visit? We should add analytics, don’t you think?”

But the other wolf pointed out, “Remember the Old Internet? Where folks would just, make cool stuff and send it out there?” … and I do remember the Old Internet. Like a lot of you, I miss having that digital creative space to connect and communicate.

…so there aren’t KPIs for More Good Work Talk. There isn’t a little view counter at the bottom. Github Pages might gather analytics but I’ve never seen them. This is, for me, a call back to the Internet of my youth: more of a place for humans, building things and sharing them because that’s a fun and interesting way to spend time.

I think I’ll keep building little toys like this – little ways to introduce play into my professional development. I am going to call it Work Play. There may never be any more, but there is at least one. If it’s helpful for you, please do keep using it – but you’ll never get an NPS survey about it, mark my words!

Goals for Upleveling Your Product Team

Goals for Upleveling Your Product Team

There’s a lot of content out there about metrics – OKRs, KPIs, AARRR, LTV, ARPU etc etc. There’s even some thoughts on this very blog about metrics (Metrics, Means and Maps, Cogitating on ROAS, It’s Good that Data is Man Made).

When product folks talk about measuring our team’s success, we always talk about the success of the things we build. Ideally the customer- or business-level outcomes that we want to achieve.

“This quarter we’ve prioritized reducing churn within the first seven days of a customer activation by at least ten percent. We can now observe that in six of our seven regions, churn has gone down by at least eight percent – we’re over halfway to our goal.”

There are still a lot of teams with the bad habit of measuring how MUCH they build – “We shipped fourteen new features this year!” – which is different than how something has impacted customers, the market, or the business. I know there are a lot of “Outcomes Over Outputs” folks, and to be clear, I’m not saying you shouldn’t ever measure output. Sometimes, in some organizations, it can be exactly what you need to do.

That’s a space to explore in a different post, I think.

It’s important – I’d even say mandatory, to measure and understand the success of the products that we build. What is missing in many cases is measuring the success of the team itself. If your product team were a product itself, how would you measure its success over time?

(Also worth mentioning, of course; teams don’t exist, but people do. )

When you’re leading a team, or building an organization, when thinking about the long term growth, you should be thinking seriously about how you’re investing in the success of the people on the team, and how to measure that over time, the same way you would for a new launch, a new product, or a new campaign.

Over a long enough time horizon, your team’s ability to accomplish those key business moving goals (decrease churn, grow customer base, improve LTV, move into a new market, etc) is downstream of this team development work. Building a strong team, and spending at least some time on how you keep that team improving over the long haul, is enormously high leverage.

Investing intentionally in the health, growth, and success of the professionals on your team also has an impact on your team’s retention, and ability to attract new talent.

These are the metrics that we use on my team – I’ll list them now, and then do a little commentary (as I do!). We’re sticking with these for 2024 (we do monthly in-team goal reviews and quarterly roundtables with our key partners) but there are some changes I think coming for next year. They’re sets of two metrics, in five themes or tenets.

2024 Team Development goals:

We Rise Together

  • Run monthly Product Jam sessions
  • Initiate 1x Development Opportunity per quarter (book club, speaker session, skillshare workshop, etc)

When I think about, “We Rise Together,” the “Together” is really broadly inclusive: it’s about creating opportunities for broad development and network growth within Disney. Disney has hundreds of product managers from cruises to in-park mobile apps to streaming players. Bringing folks together, to share skills and insights, and being visibly the team that is committed to doing so, generates a lot of positive visibility for the folks on the team, and makes new partnerships and internal collaboration opportunities much lower-friction.

It’s also quite fun! I personally get a lot out of a book club or tech talk; and it’s a nice forcing function to get me to actually read the new Cagan instead of scrolling Slack. Product Jam is a monthly 60-minute call where a member of the product org gives a talk or proposes a blog post or podcast to lead a discussion on. It’s quite casual but it’s a great chance to get to see folks around the org.

The tenet name is aspirational: we want to make our team better but not if it comes at the expense of our peers. It is also the first tenet on purpose: we rise but we rise together. Product is a team game, and supporting our colleagues and investing in the broader product org always bears positive dividends.

We See Far

  • Schedule 1:1s with PMs outside of Media Product 2x per Quarter
  • Schedule 1:1s with PMs outside of Disney Streaming 2x per Year

“Media Product” is the VP-level organization that we’re a part of. My direct lead is a Director, his direct lead is our VP. A PM outside of Media Product might work on the mobile app for Disney World, or the syndicator feeds for ABC, or the A/B testing framework for the streaming platform.

The important thing about this goal is that it helps us get out of our bubble: it’s very easy to get your nose so close to the grindstone that you lose sight of what else is happening around you. Taking some time to get to know folks outside of your direct team, as well as folks fully outside of our firm, helps to set a broader context about what’s happening in our company, as well as in the product field at large.

We See Far and We Rise Together are often contributive to one another: you have an intro 1:1 with someone, and they end up being an excellent Product Jam speaker. You get an intro to a PM working in an interesting startup from someone at book club.

We Care About Quality

  • Every L-XL+ project gets a Looker Dashboard & a Retro
  • Formally seek feedback from Engineering Teams Quarterly

This one is about great habits: we need to keep a pulse on how our projects perform, and how we might iterate on them in the future. To do this effectively, we have to intentionally build out the infrastructure that will fuel that awareness and iteration. The Looker piece just happens to be the tool we use – the tool is less important than getting in the habit of creating dashboards by default.

Any project sufficiently large to mandate a dashboard should also already have at least one retro scheduled by the engineering side of the house; but Product isn’t always invited to them. If it’s possible, I really like to sit in on those calls – they can often be a source of really helpful insight into process and approach, as well as feedback for how you personally are doing with a given team.

For the engineering feedback piece, we use a fairly simple Google Form, with a standard NPS metric and a few ethnographic and a few feedback questions. We schedule them in conversation with engineering leadership so we’re not asking engineers to fill out a survey in the midst of a stressful crunch time, or when lots of folks are on vacation.

There’s no perfect Product Manager, only the Product Manager that uses their product toolkit to best effect with the engineering teams they work with. Retros and quarterly surveys are a great source of insight as to how well your team is performing in that space.

Become Aware

  • Each PM attends at least 1 trade show in our industry per year
  • Each PM attends at least 1 Product focused event per year

This falls in much the same theme as above – a ‘trade show’ would be something like NAB in Las Vegas, a chance to connect with vendors, understand our space in the broader media and entertainment space, and walk around a gigantic trade show floor. A Product focused event would be something like Product Con or Lead Dev, maybe An Event Apart.

A theme-of-themes here is “get out of the office,” – mentally, network-wise, and literally physically. I am a firm believer that innovation emerges from novel intersections, unique combinations of experiences and expertise that are rare but valuable, and the most expedient way to achieve novel intersections is to get out there and experience a bunch of things.

Cause Awareness

  • Each PM speaks 1x per year at an external event or conference
  • Each PM speaks 1x per year at an internal event or conference

Becoming Aware and Causing Awareness are collaborative tenets as well – often we can check a couple boxes at a single event. I think for product folks, investing in public speaking, in clear communication, is so important, and is such a highly portable skill, even if folks I work with leave product forever (not because of me, I hope!), being clear communicators who can talk confidently in front of a room will serve them where-ever their journey takes them.

While the actual giving-a-talk is what’s being measured here, I feel that the preparation of a talk is in some ways at least as valuable as the experience of giving it. Much like blog posts, preparing a talk forces you to distill your thinking into something crisp, to take a position, and defend it to strangers.

Maybe at the end of the year I can do a roundup of how we’ve performed against these goals – and which ones we are shaking up vs. keeping as-is. It could be valuable to reflect on how setting them has been productive, or could be improved. Stay tuned!

Product Toolkit: Quick Proposal

Product Toolkit: Quick Proposal

(if you’re just looking for a link to the QP template, here it is!)

This post is the first in what I hope will be a recurring series where I share some of the tools that I use, and work with my team to develop, in our product practice. In this way I hope to show our work, make the role of the Product org more transparent and accessible, and maybe help folks find success in their professional life (or maybe personal life, who knows!)

You’ll hear a lot of opinions about the role of Product Managers. They’re probably all right in their own way. Realistically, different teams will leverage the title “Product Manager” in really different ways. Sometimes it’s predictable; Product at a seed stage startup is going to be incredibly in the weeds and will wear about thirty hats. Product at a big legacy company needs to think more about organizational topology and cross functional buy in.

This is even setting aside the great controversy of “Product Work,” as in, “We’re not even spending our time doing Product Work,” which is a whole different and interesting conversation.

I’ve settled on a position, as one must, in these matters. It’s my sense that the most important thing a good Product team does, is they work very hard to avoid building the wrong thing. There are a lot of tools and approaches, mindsets and strategies, but a good Product organization should mostly be focused on maximizing a firm’s opportunity to get it right, and the fastest and most effective route there is to minimize time spent building the wrong thing.

There’s a lot written about Product Discovery (there’s even some right on this blog!) – if you’re curious more generally about how to assess opportunities, talk to customers, and why it’s important, I recommend starting with the singular Teresa Torres and her excellent book, Continuous Discovery Habits.

Discovery within an organization, finding ways to gain a better understanding of what’s going on within your company, how to get things done, getting sufficient input from the right folks, is a key input to Not Building The Wrong Thing. The thing is, it can be quite a lot different from interviewing customers and reviewing AARRR funnel exercises.

For one thing, these people have a fundamentally different relationship with you than your customers do. Ideally, they have an actual relationship with you! You work together, you have shared interests and (hopefully!) are aligned on what it means to find success in the upcoming quarter, year, and so forth.

They’re also busy, and unlike your customers, there can be a lot at stake in their interactions with a product person, even one with great intentions, even one with whom they’re aligned. Seasoned professionals are also very aware of the challenge of building things within larger companies, and the amount of uncertainty and potential risk to their own careers, especially around taking big swings.

There is a pattern of behavior here that I have seen myself, and have heard discussed many times in product circles, where it feels like nothing can gain purchase on the actual backlog of real, living engineering and operational teams. It feels like you’re stuck in a cycle of meetings, discussing at a high level the trade offs, propriety, the sensibility of a given possible piece of work.

You’re stuck in Abstract Land and just want to clear the air, and get something moving.

(There’s a blog post here about, platform product teams serving the role of uncertainty sponges, maybe?)

It’s not that your partners and stakeholders are doing anything wrong, or malicious – in fact, like you, they’re behaving in accordance with their rational incentives. It can be challenging to get out of high level abstract space and down to decisions, in part because:

  • Folks don’t want to get it wrong: the fewer calls you make, the easier it is to avoid getting it wrong
  • The abstract space is easier to be misunderstood / misaligned: if you and your colleague are saying things that are sort of aligned, in the fuzzy abstract, that’s fine.
  • Folks don’t want to give direct feedback to a colleague. It’s much easier to correct a representative from a company you pay for a product from, than someone you might work with or need help from in the future.

One way to get out of this space is with a Quick Proposal. A Quick Proposal is a tool in the product toolkit that leverages one of the fundamental laws of the internet:

“The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer.”


Cunningham’s Law

A Quick Proposal is just that – a short written summary that offers your partners and stakeholders a chance to correct, update, and provide feedback on a document that takes a position, rather than staying in an abstract space.

Features of a good QP:

  • It is one page long, and dated
  • It is written in under 20 minutes
  • It is in a format that everyone at your firm can access and comment upon
  • It contains a brief round-up of what is known about the space under discussion
  • It links out to other existing documentation, research, data, etc.
  • It has a section called “Recommendation” which contains your best bet for the next action to be taken given the discovery and discussions that have occurred.

While a QP can help to spur action, it isn’t necessarily meant to be acted upon – it’s meant to:

  • Capture your best understanding of a situation in as specific terms as possible
  • Create at least one possible recommendation for next steps based on that understanding
  • Generate a target for stakeholder feedback that isn’t another person, but a document

The way to use a QP is to present it as a loosely held summary – not, “I believe this is what we should do next, what do you think?” but more, “We have a lot of threads here, so I’m taking a crack at getting everything together. Does this look right to you?”

I’d also recommend when requesting feedback that you ask specific, relevant people directly, you provide a date by which time you’d like to make a decision, and you extend the offer for feedback to anyone else they’d recommend as having a voice in the matter.

A QP sometimes ends up being developed into a go-to-backlog type document (a One Pager, a Product Brief, a Product Requirements Document) but it’s real capital-J Job is to get your group and project out of the strategic stratosphere of Abstract Land and down to tangible discussions of what to do, how to do it, and when it can be scheduled, or, in the pursuit of Not Doing The Wrong Thing, perhaps it is set aside for other, more appealing opportunities; that’s also a win!

Here’s a Google Doc Template if it’s helpful!

Advice to My Younger Self: Always Ask

I’ve been in the workforce for a while now.

During a meetup in London with the data team at Automattic, for my turn at a flash talk I gave a Brief Unabridged Resume, writing out my full professional timeline on post-it notes laid out on the wall of an AirBNB in Westminster. It took about forty minutes and wiped out the sticky notes!

I’ve only had two jobs since then (things have calmed down some for me, professionally!) but I do still look back and sometimes wish I could take things I’ve learned and beam them back into my younger self’s brain.

(Not that my younger self would listen!)

There’s a way of re-framing embarrassment and shame about your behavior and decorum during your early days, which goes something like, “If you look back and are embarrassed by what you did, or said, that means you’ve learned from it, and you won’t make that same mistake again.”

This has been a helpful mental model for looking back on things that clearly did not go well – but when I think about advice to my younger self, I am thinking more about how things could have gone much better, not necessarily eliminating regret. What are the things I’d suggest, that would have had the highest leverage?

(Or, as this exercise implies, what I today would expect to have the highest leverage – maybe in another 13 years I’ll write another series about how my advice to my younger self was all wrong!)

The first high leverage bit of advice here, for me, as a younger professional, would be, ask more questions.

Now, folks who have worked with me, or who have followed this blog (#,#) might find this a little confusing – I’ve always been a bit of a question-asker, definitely a talk-to-thinker, but I have often let fear and concern about how others perceived me, to shape what I was and was not up to explore in conversation.

Now, this isn’t to say, that a good professional, a good Product person, is tactless and without consideration as to how their questions or behavior is perceived – that’s very important in fact. I mean more, and perhaps this is only really clear to any person in retrospect, that we must know ourselves, and try to move forward driven with intention rather than be driven by our background, upbringing or personal history.

(What a sentence! Might be getting outside my lane a bit here)

I grew up in a pretty classic rural setting in late-20th century America – when folks hear New York they picture the skyscrapers of Manhattan, but there’s a lot more to the state. Westernville, NY is just over a four hour drive from the city, and I have a lot to be grateful for, having it as a hometown. One piece of it, though, was a real sense of anxiety around asking questions, especially in a professional setting.

Upon reflection, much of my professional success has come only after learning to ask good questions, and to set my own fear of being seen as silly or uninformed aside. It helped me to look at my workplace with a greater sense of humility, too, when I was able to start to feel safe expressing things I didn’t know, or didn’t feel I really understood well.

In a healthy professional culture, folks will be game to explore and explain. All human endeavors are more complicated than you think – there’s a whole well studied psychological Effect about how bad our brains are at understanding the complexity of things we don’t know much about. It’s almost always good to ask more questions – about the products that you use, about how different teams work together, about other folks’ understanding of a complicated situation.

A professional workplace is one where folks engage with questions thoughtfully and in good faith – especially given that to ask a question can be indicative of a possible mis-alignment somewhere else in the organization or architecture, and someone saying, “Wait, can you explain that a little more?” isn’t because they weren’t listening – but because they’re digging for deeper problems.

Especially for internal or platform PMs, you must get good at this – understanding the bare-metal Capital-T truth of how things work and get done at your organization is a huge factor in your ability to steer toward your organization’s goals (and your personal goals!)

(There is of course the situation where, there is no Capital-T Truth to be found, which is a situation for a whole different post)

Note that sometimes this means product or technical questions like, “Can you explain to me how these services interact? How do we get data from here to there?” as well as, “Can you help me understand how your team, Frances’ team, and Jean’s teams work together? Who is responsible for what?” – these can both be serious areas of confusion, uncertainty, and friction within a firm, especially when the answers are different from person to person!

It isn’t so unusual for folks who have been in the workforce for a while to have seen the ugly side of the Dunning Kroger Effect – it feels like every software engineer and data analyst has a story about a colleague confidently displaying a shocking lack of interest or understanding of their area or way of working – “And then Product said, can we just add a column for ARPU?” – “Can we squeeze in an Okta integration this sprint?”

When we are able to come to the table representing (rather than misplaced confidence!) a curiosity to learn more and the will to overcome our own fear and anxiety, we build better relationships, better organizations, and in the end, better products.

Incentives: Invisible and Important

Incentives: Invisible and Important

I’ve had the good fortune of getting a lot of advice from folks who are farther along in their careers – either greater velocity, higher heights, more reps on the work, really a diverse crew of mentors and advisors.

During one of these conversations I was given the advice, to shift my thinking when it came to partners and stakeholders within the company, away from broader business goals, and instead try to focus on and get crisp on individual peoples’ incentives. Incentives, they pointed out, often illustrate someone’s motivation and behavior better than any other factor.

Teams at the end of the day are collections of people, and people (not teams) have relationships – but we have to remember that they also have motivations and incentives to do the things that they do. Especially at work, no one is a chaos agent, not really; folks are busy, and are trying to do the right thing for themselves, and for their team, and for their family.

I’m sure pure spite-based actions have happened, but the vast majority of the time, no one is actively working to frustrate or bypass you, your team, or your work. It’s true when we tell our kids and it’s true as adults: no one is thinking about you as much as you are. There is almost always a more parsimonious explanation that does not involve malicious intent. And, since malice and spite are not good predictors of future behavior, they’re not super useful in your mental model.

Like Heinlein tells us, we’re better off understanding and appealing to someone else’s self interest – similarly to how Ferrazzi describes co-elevation in “Leading Without Authority” (a great read for anyone working across multiple teams or organizations in any context), you have to understand what someone else perceives as valuable before you can start to explore what a mutual win would look like.

It feels obvious in retrospect – folks want to achieve a win, and we of course want to pursue our own success, but figuring out the way that those puzzle pieces can fit together can be much less clear. The problem of course, is that incentives are invisible. We don’t always even understand why we ourselves do what we do, how can we possibly hope to understand what is driving other people?

We have two kids (the featured image is us at Meow Wolf in March!) – they’re nine and seven. Our daughter, unbelievably, turns ten in May! They sometimes experience a flavor of this same social space. If a friend is unexpectedly unkind, or a coach or teacher says something that surprises them, we like to use the “Something Missing” framework to think it through.

“That doesn’t sound like something she would normally do – is there something missing that would help explain it?”

… often for kiddos it’s something like, having trouble with another friend, or losing in a game, and for teachers and coaches it’s often grounded in wanting a particular goal for the whole class or team. In a way that a lot of things start to stitch together, this Something Missing prompt also become a useful framework for me to think about my relationships in the workplace – “What incentive is missing here? What part of their landscape am I not seeing, that explains this behavior?”

Often the simple act of prompting myself to accept that there may exist some invisible factor that is not yet known to me, can be helpful to set aside my own (sometimes hurt!) feelings, and instead move into investigation and resolution.