This article originally appeared on BryceYork.com.
As we start a new decade, I took a lot of time to reflect on my nearly ten years working in product. I took a lot of notes on the lessons I’ve learned along the way, and this essay shortlists the top 10, prioritized by practicality and non-obviousness so I could feature things we don’t see spoken about all that often.
No. 1. Talk to your users more
I know, I know. I promised you in the title that this would be non-obvious tips. This is the one exception because it really can’t be overstated.
I know how easy it is to procrastinate speaking to your users. For most product managers, it’s nowhere near the top of the favorite things to do.
Speaking to users is one of the single highest leverage activities a product leader can do. In essence, our job is to advocate for users and build product that meets their needs. Ideally, we do that in a way that generates profit. To do that job well, you have to know our customers intimately, and there’s no substitute for talking to them directly (ideally, one-on-one).
If you’re already talking to your customers regularly, would it hurt to do it more often? Are you involving your team? Are you sharing your notes and recordings? Are you focusing too much on problems or solutions?
If you search google for advice about talking to your users more, you get 618 million results! What’s even more impressive is that searching for “bacon” only has around 8% more results.
It’s clearly been said a lot that you should talk to your users more, but we’re all guilty of putting it off and doing it less often than we think we should.
Set yourself a goal for this year. How many users do you want to talk to each month? Now go and block out time in your calendar for customer interviews and time to plan/schedule those interviews.
No. 2. Take a balanced portfolio approach
You wouldn’t have to look very hard to find 100 articles on roadmap prioritization. It’s a popular topic — I suspect at least part of why is it being as much art as science. One standard approach to roadmap prioritization is to take all the things you want to work on for the quarter/year and rank them 1-to-n.
How do you rank them? Another vast topic, but the most popular and practical methods use a set of criteria with associated scores and an “algorithm” for rolling the scores up to a single number. Then you just rank the list from highest to lowest score. What kind of criteria do they use? Most systems incorporate some form of business impact, risk, and effort. Another popular method is to give each person in the group a fixed number of votes to apply against the full list of options (sometimes allowing multiple votes on each item) and then ranking the options based on total votes given across the group.
Across the teams I’ve worked in, advised, and consulted with, this approach of taking a giant punch list of ideas and force-ranking them is probably the most-used approach I’ve seen in my career. But I see some significant flaws in this approach and prefer a different one — one that’s only marginally more effort.
Generally, taking a long list of ideas and ranking them leaves you to figure out your strategy after you’ve figured out your tactics. It’s backward!
And even if you lay out your strategy first, there’s not a lot guiding the prioritization process towards aligning with the strategy.
The single-list approach tends to leave you very focused on a certain kind of work, essentially putting all your eggs in one basket. At the end of the process, you’ll probably end up with a highly-concentrated focus that amplifies any blind spots or weaknesses you’ve already got.
Before you write off this approach, it’s not always a terrible idea! If you’ve got a smaller engineering and product team, this approach is probably your best bet. Save your energy for moving fast, learning quickly, and focusing your energy. Plus, if you’ve essentially got a single team in your product and engineering organization, the portfolio method won’t work out-of-the-box. Feel free to read on, but I’d suggest applying this abstractly rather than literally.
Once you have multiple product teams, I think there’s a better way.
The approach I actively recommend using for roadmap prioritization is centered on thinking about your product and engineering efforts like an investment portfolio.
Let’s say you’ve already got your list of projects. Before you start ranking them, let’s “cluster” them into groups or categories.
Ideally, these categories link to the customer impact, value mechanism, or business metrics they’re expected to impact. If you’re feeling stuck, try to group them before you think about what you’re grouping them by.
It’s easiest if you can do it with Post-its on a wall (last time I did this, it was via video call across New York, Toronto, and Los Angeles).
If you’d rather stay digital, choose something that’s super flexible and won’t slow you down. A simple Excel sheet or virtual whiteboard like Miro would be my first choice.
Ideally, you’ll land on enough groups to average 1-2 product teams per category. As you’re planning, keep in mind how flexible your current team structure is –- nobody wants to be in the habit of a quarterly restructure.
Once you’ve got your proposed clusters, take it to the leadership table and decide how you want to split your resources and energy across the categories. I’d caution against taking the easy way out of splitting things evenly (e.g., you have four themes that each get 25% of resources). It might seem like the “balanced approach,” but chances are you’ll take longer to deliver meaningful value than if you were more focused.
I’ve seen the best results when you have one cluster with the lion’s share of resources. The size of your team will impact how many themes you’ll want to execute on at a time. The bottom line for me is that an individual project (a line item on your upcoming roadmap) should virtually never have less than two engineers working on it.
By way of example, the last time I did this, we landed on six categories. For the upcoming quarter, we put 70% of our effort into our main category and 15% into each of our two secondary categories.
If you’re looking at an annual plan, aim to be most specific about the first quarter with more flexibility later in the year (since things change). I’m a big advocate of the “now, next, later” roadmap popularized by Janna Bastow from ProdPad. The basic approach here is to have three time horizons on your roadmap with decreasing levels of specificity and, importantly, no timelines outside the first time horizon.
Now that you’ve determined an allocation across your chosen set of themes, you’ve got the investment thesis for your product portfolio!
Let’s take that investment thesis and turn your list of projects into a strategically-aligned roadmap. For each bucket of projects, apply the same method you would have used to rank your single-list of projects. Agree on the criteria, ranges (1-3 or 1-5 work best), and the “algorithm” to turn the scores on an item into a single overall score. Often your algorithm will just be simply to sum the ratings. Or, you may want to weigh each criterion differently depending on your overarching product strategy (e.g., up-weight ease of execution to have your roadmap focus on quick wins and low-hanging fruit).
With each bucket ranked, you can figure out how far down the list you’ll get with the available resources and can draw a “cut line” for what’s not going to make the cut (and set expectations accordingly).
Taking this approach isn’t going to work for everyone, but in my experience, it sets you up for a more strategy-driven approach. In particular, you’re much more likely to put energy into the important but non-urgent work I’ll explore more in tip no. 5.
No. 3. Develop a single source of truth for your product initiatives
Sounds simple, right? Not necessarily… In a way, this is a perennial problem. I’ve advised, consulted for, and worked at many companies. Only a tiny subset had this simple principle covered. Some had no reliable source of product department work, and many more had a highly fractured, often conflicting jumble of information spread across multiple tools (Jira, spreadsheets, docs, meeting notes, and Slack).
In your current organization, where do people go if they want to know:
- What is product working on right now?
- When will feature X ship?
- What is project Y all about?
- Who’s working on feature Z?
There are two vital criteria for having a “single source of truth:”
- One document (or tool) for the whole company; and
- Everyone in the company knows where to find it (and, of course, has access to it).
It’s also vital this document be kept up-to-date. The common gotcha here is that if there’s too much detail or structure to the document, it will end up rarely getting updated. Plus, you’ll risk people not understanding what’s going on and having to ask somebody anyway.
There’s a tricky challenge here because your engineering colleagues will probably suggest that Jira epics solve this problem. That may be true… But I can honestly say, I’ve found Jira to be the single worst tool for this job. It’s intimidating, convoluted, hard to configure, and very often falls out of date because it’s such an effort to update.
I previously wrote about one of my preferred approaches to project status reporting using Google Slides. That system is perfect for organizations that want a lot of detail and depth.
If your company is open to a lighter touch that keeps it simple and easy to understand, I’d stick to the essentials:
- A public roadmap (what’s being worked on, why, and by whom)
- Periodic status updates (Are things on track? What’s happening next?)
- Where to find out more about the project (give people a clear path to understanding the why and what of a project).
At my current company, we’re trying out Coda for this, but any good wiki tool (Notion, Confluence, Basecamp) will get the job done.
As the owner of this system, you’re going to have a recurring battle to fight — the “one more thing” problem…
You’ll get constant input from stakeholders asking you to add just “one more thing” to the hub. You certainly shouldn’t say no to everything, but you’ll want to say no to a lot …
Part of what makes a system like that is keeping it simple. After all, your primary audience for this system is going to be C-level executives.
If you try to make a single document that communicates everything about a project and what stage of a giant multi-step workflow it’s in, you’re going to struggle to keep it up-to-date. Most people aren’t going to use all the information that’s there. And worse, the sheer overwhelming wall of information will probably dissuade them from even using the tool.
As a rule, less is more.
One other thing to strive for is a layered approach.
Focus on offering a very high-level summary with multiple layers of detail so people can choose their own adventure.
Sometimes a stakeholder just wants the top level while they’re grabbing coffee; other times, they really want to dive into the weeds.<
Ideally, they can achieve both goals without having to talk to someone. Not to say speaking to someone is bad, just that you’re better off using that time for more complex questions. Plus, it saves people being put on the spot when the CEO asks, “When is X going live?”
No. 4. Cultivate a template and checklist culture
There’s something truly grating about feeling like you’re constantly reinventing the wheel. My go-to tools for that frustration are checklists and templates. There’s so much communication overhead and tire-spinning to be saved by using simple templates and checklists.
Unfortunately, I don’t have some magic system for instantly creating them, but I can say they’re well worth the effort.
In my experience, the best checklists are pretty short. Generally, under a dozen items.
Worried people are going to feel patronized for being asked to follow a checklist?
Keep in mind that basically, everything a pilot does is based on a checklist! On an average flight, the pilot(s) will go through 8-10 checklists. Even those that have 1000s of hours of flight experience, still read and follow the checklist.
Looking for prime checklist opportunities? Here are a few I’ve found useful in the past:
- Pre-launch checklist
- Go-to-market checklist
- Project kickoff checklist
- Post-incident checklist
In my experience, the best checklists simply live in your existing wiki tool (Coda, Notion, Confluence, etc.) rather than some fancy dedicated tool.
What about templates?
They’ll help solve similar problems where the fix is more about structure and prompts than taking specific actions. Good candidates for creating a template are more about the content or documentation that’s created than actually doing a set of things. Sometimes you’ll want to pair the two together. Once again, templates are best placed in a central part of your wiki tool.
Some helpful templates I’ve developed and used extensively:
- Project plan template
- Project kickoff template
- Business case template
- Launch email template
- Project retrospective template
One way to spot candidates is to look out for frequent and consistent activities. Especially those where the cost of a mistake (or missed stepped) can be high. High-cost often isn’t tied to labor. High-cost mistakes often hurt the confidence/perceptions of your customer, market, or stakeholders. Usually related to the downside of imperfection, things falling through the cracks, things not getting done. A typical example is something that looks bad to your end-user or significantly compromises their product experience.
I know this isn’t a groundbreaking strategy, but I’ve found it really pays dividends to invest in high-quality processes. Even though it can feel tedious and trivial, you’ll be glad you did the work. More on this in tip no. 5.
No. 5. Get the paper cut problems onto your roadmap
What’s a paper cut problem? Well, do you remember the last time you got one? It hurts. Disproportionately.
A paper cut problem in the product context is usually a part of the product that’s painful to use but not enough that your user is going to churn. Much like the whole “death by 1000 paper cuts” thing, if you have enough of these problems in your product, they’ll drive users away.
Side note: Random tangent, but growing up, I had this latent fear of getting a pair of paper cuts where my top and bottom lips meet. Strange, I know, but now I’m reliving it. And now I’m wondering whether it was a peculiar and irrational fear or whether I did it to myself and just buried the memory … For the morbidly curious, it turns out the Jackass crew did it.
Paper cut problems are usually the last thing to get prioritized. Especially in a culture that’s obsessed with shipping and velocity (trust me, I’ve been there). You know, the teams who tend to focus on new features at the cost of all else.
One way to think of these problems is like UX debt (in the same vein as the always-contentious tech debt). Tech debt itself can even be seen as an internal paper cut problem.
Frequently, you’ll find just as many paper cut problems inside your product processes as in the product itself.
Think about your prioritization process or your engineering release workflow. How streamlined are they? How much do you (or others) dread them?
These, too, are paper cut problems. They might not slow you down much on their own, but stacked up, they can severely hamper the productivity of a product team.
Externally, paper cut problems tend to show themselves as clunky UX flows that work but feel tedious. One of my colleagues even coined the term “war on clicks” to encourage a spike to resolve these paper cut problems on an internal product.
Looking at the painful UX workflows, try prioritizing using a balance of frequency, the severity of frustration, and ease of resolving.
What’s an example of a paper cut problem? Generally, it’s something associated with rolling your eyes, sighing, or saying “ugh” out loud. Things like …
- Having to restart every 3-4 deployments because they fail — there’s no customer impact, but it’s annoying and tedious.
- Having to log in again every time you come back to the product (when there’s not a good security reason for that).
- Slow loading features that you use every day.
- Forms you have to fill out regularly but don’t show the right keyboard (e.g. a phone number that shows the whole keyboard)
So what do we do about our paper cur problems? I’d strongly suggest finding a place for these projects on your roadmap.
Depending on the scale of your paper cut problems, adjust the level of resourcing you need. A good starting point might be putting two engineers on it for 1-2 months.
A warning, though — don’t try to add individual paper cuts to the roadmap. Instead, choose your resourcing plan and then set it as a mission to “solve important paper cut problems” (or similar). That way, the focus is on making meaningful progress, rather than solving singular problems. You’re also probably not the best-placed person to know what should be prioritized; instead, coach the team to figure it out for themselves.
No. 6. Slow down to speed up
I’m sure we can all agree that premature optimization is the root of all evil. After all, part of our job is to advocate for reducing waste, taking an experimentation-driven approach, and shipping MVPs, not over-baked mega-projects.
But over time, parts of your product and operations will begin to mature.
You’ll probably notice certain things don’t need changing all the time …
When it gets to this point, remind yourself that it’s okay to go long on things and invest in optimization once assumptions are validated and key risks mitigated.
I think most product leaders are great at this when it comes to their products. After all, many of us ended up product people because we like creating exceptional products.
But when it comes to process and tooling, it’s much easier to skip the iterations and get by with the bare minimum.
Often, the candidates for putting this tip into practice also surface as paper cut problems. When thinking about places to “slow down to speed up,” be sure to look beyond just the product department and explore engineering, operations, and other departments to see how a small product and engineering investment could substantially boost their productivity or quality of life.
Wondering where else to look? Some common hiding places in engineering include DevOps, CI/CD tooling, automated testing, design systems, infrastructure. For operations, consider finance automation, client onboarding, demonstration accounts, and automated reports.
Try it out, give one of your teams a break from shipping new features to customers, and invest their talents into behind-the-scenes or under-the-hood projects — especially the ones that, when successful, will set up the whole department to ship faster and with more certainty.
No. 7. Get serious about meeting etiquette
Meetings are a love-hate part of life as a product leader. We all spend a lot of time in meetings, but chances are we’re the ones responsible for organizing a lot of them.
When you’re running a meeting, there’s plenty of easy ways to accidentally make it unproductive, frustrating, or otherwise less than ideal. Not every meeting will be perfect, but now is an excellent time to set the habit of avoiding some of the common pitfalls.
There’s plenty of cliché methods you’ve no doubt heard 37 times. Things like always having an agenda, but I’ll stick to some of the less worn out ones (though you definitely should always have an agenda).
If it’s a video call, I think it’s worth calling out some specific tips first. I’ve spent 6+ years working with distributed teams and know firsthand how much of a difference small changes can make.
- Everybody mute their microphone unless they’re speaking
- Strive for everyone to have a camera on, even individuals in a conference room together. It makes a massive difference to the power dynamic when everyone feels on the same level. Ever had a 100% remote meeting and felt like it just went better? This is why.
- Don’t expect your Bluetooth audio to work, Murphy’s law says it won’t. Test your sound before the meeting, and personally, I just opt to use the cable on my headphones rather than rely on Bluetooth and drive everyone nuts with the “can you hear me? I can’t hear you” loop.
With those three video call tips in mind, what about meetings in general? Here’s what I’ve learned over the last ten years that I think will help your meetings run smoothly.
- Decide in advance who’s screen sharing and who’s taking notes. I’d hate to count how many hours I’ve spent in meetings where everyone stays silent when the HiPPO (Highest Paid Person) asks, “Who’s going to take notes.” It can be a lot of work, but being the note taker is an excellent opportunity to improve your visibility in the department and/or company. If you’re going to ask someone else to write the notes, don’t always ask the same person “because they’re good at it.” It’s a tough job, and it impacts your ability to participate in the conversation.
- Share notes as publicly as you can. If parts of the agenda are suitable for publishing to the whole team, department, or company, do it. I’ve found it works best to keep rough notes during the meeting and annotate any topics that are off the public record. Then when compiling the notes, you can publish the private sections separately and share those on a need-to-know basis.
- Institute “the law of two feet.” I don’t remember where I first heard it, but I’ve followed it (and tried to share it around) ever since. If you’re in a meeting where you aren’t adding value and aren’t getting value from it, get on your feet and leave. No point wasting valuable time in a meeting that’s gone in a different direction than expected and is no longer relevant. Making this a habit can even save whole meetings that can be skipped because, for whatever reason, there’s not a productive conversation to be had around the agenda. Make sure you emphasize that people don’t need to justify themselves when they leave, just a simple “I’m going to drop off here, thanks all” or similar should be considered the appropriate behavior.
No. 8. Fight for fixed-time and variable scope
Scope creep. 😩 Missed deadlines. 😐 All but inevitable when you’re building software.
And yet, it still feels totally impossible to plan for …
There’s never enough padding, and there always seems to be some unforeseen but “must-have” feature that’s added to the spec at the eleventh hour.
To be honest, I doubt anyone working in product enjoys managing deadlines or estimates. Especially since we’re regularly left convincing the engineering team to give “better” estimates and holding them accountable for them.
Imagine you’re working on a project, you’re at least halfway through. But now you’ve realized you’ve underestimated or the scope changes dramatically. If you want to still ship on time, you’ve got two main levers to pull: velocity and scope.
Unfortunately, the most common approach is to focus on velocity. But that’s how you end up like the gaming industry. With people working insane hours to deliver immense amounts of work before the deadline.
Like the Basecamp founders, Tobias Lutke (founder of Shopify), and many others, I choose to avoid that path with my teams.
Most of the time, we resort to padding the estimate to cover our butts. I’d bet most of us even have a go-to multiple for adjusting an estimate given by our engineering team before we share it with stakeholders. I’ll be honest, I’ve had one.
If you can get people to buy into it, I think there’s a better way (as the primary defense, you’ll probably still need to pad things but for a different reason).
For a few years, I’ve sought to convince “management” to take a more loosely defined approach to exactly what deliverable defines a particular deadline.
That way, we can work towards the deadline and adjust the scope to fit (instead of extending the deadline).
While this doesn’t really work for an MVP (since you’re already supposed to be delivering the bare minimum functionality), it works well for iterations and less experimental projects.
It was always a long conversation and extended negotiation trying to win people over to this less traditional approach. But last year, I read a book that helped put forward a really compelling argument. Plus, it has the bonus angle of “if it works for them, it’ll work for us.” That book was Shape Up by Ryan Singer from Basecamp.
Among many other tactics, he summarized the same approach I’d been taking in a simple one-liner: “fixed-timeline, variable scope.”
Pretty elegant, right?
So now I knew my little hack wasn’t my little hack after all.
Taking this approach embraces that we’ll never know upfront when a specific deliverable will be done. It also acknowledges that in a business context, having no deadlines is largely unrealistic – part of that being the amount of downstream work that needs to be sequenced and planned based on when a project ships (such a marketing and comms).
Now, when kicking off a project, try setting the timeline based on how valuable you expect the result to be — not the scope of the project.
Planning a project that’s guaranteed to make $10M in incremental profit? Probably worth putting a lot of resources into it and giving them plenty of time. Got a project that’s likely to save $20k a year in infrastructure fees? Don’t put a team of engineers on it full time for three months.
Of course, most projects won’t be nearly as easy to calculate a cost-benefit, but you get the idea.
Now use the timeline and resources you’re willing to ‘bet’ to determine how big the scope can/should be. How extensive can your solution be given the time & resources you’re ready to invest?
Often these constraints will set you up to develop a more creative solution. Like Charles Eames famously said, “design is constraint.”
The fixed-timeline approach won’t work everywhere, but it’s well worth trying it out if you can. At the very least, it’s helpful to think about whether your investment in a project matches the expected outcome and to remind ourselves that there’s more than one way to cook an egg.
No. 9. Turn solutions into problems
👆 Counterintuitive, right?
You could also call this tip “the delicate art of saying no”.
Ever hear the phrase, “don’t bring me problems, bring me solutions?”
I’m sure you have. It’s basically a management cliché.
Side note: I absolutely hate this phrase — but that’s a rant for another time.
I don’t know how you feel about it, but I’ll bet you aren’t hearing product managers say it often. But it’s not because of some philosophical resentment (that’s just me). We never say it because everyone loves bringing us solutions!
If you were to build a roadmap purely on the ideas brought to you by stakeholders, you could probably keep your whole engineering team busy for years to come.
The problem with all these solutions is they’re often off-the-cuff or coming from people that just aren’t great at coming up with product solutions.
One of the core skills of a PM is taking proposed solutions (especially from users), distilling them to the underlying problem, and then developing the best solution for them from first principles.
This tip isn’t just to do that — wouldn’t be very non-obvious, would it?
Instead, let’s look at how to handle pointed input from a highly persuasive voice (like a senior executive or co-founder).
When the pre-baked solution is coming from a senior executive, even the founder of the company, it can feel like a whole different ballgame.
While running a problem interview with a random person in your target market, or (if you’ve got a lot of them) even an existing customer, it’s not too hard to resist taking their input literally or at face value. You probably won’t speak to them tomorrow, and they know they’re just one voice, so hardly expect you to go and build the exact feature exactly as they’ve suggested.
With a senior stakeholder, though … that can be a different story. Sometimes they’re even your boss!
Plus, this can all be made even tougher by how early you are in your career, your personality traits, your company culture, or your national culture.
Everywhere I’ve worked and advised, though, it’s a particularly tricky process with at least one stakeholder. Usually, someone with a strong voice and a lot of ideas that they’ll share any chance they get. Got someone like this at your company? I’m betting someone’s name or face just came to mind.
When dealing with a user or a stakeholder who knows and supports you taking things back to problems and developing your own solution, the basic process is the same.
I wouldn’t worry about trying to convey that you’re going to discard their solution and focus on the problem instead.
Acknowledge the suggestion, make sure to note it, and then dig in with clarifying questions. And let them know, the questions are to make sure you understand where they’re coming from and to ensure you truly know what they’re asking for.
If you’re dealing with internal stakeholders, you can try and directly advocate for a problem-focused approach and help nudge them towards focusing on the problem instead of trying to solve it.
You can even have a little fun with it and call people out for “solutioning.”
As a company, it’s a good muscle to build, and many times you’ll see good results.
When the time comes to develop your proposed solution, be sure to loop the stakeholder in and get their buy-in to the solution you’ve developed and thank them for their direct contribution. Give them the praise they deserve. After all, the problem is the important part. Right?
This is absolutely the ideal approach, but not everyone is open to being coached like this, and some people can’t help but fixate on solutions. Plenty of people become product managers for this reason, which has its own challenges.
How to handle “difficult” stakeholders …
If your stakeholder is strong-willed and fixated on solutions, you’ll want to take a more political approach.
You’ll want to clearly and frequently communicate that you value their input but will put in a little extra time behind the scenes to look at the problem from other angles but that you’ll circle back and get their feedback on any alternative approaches you produce.
It’s usually a good idea to make clear you’re investing a small amount of time to avoid the perception you’re over-investing in undermining what they might think is a ready-to-build solution.
You’ve got to pick your battles, though sometimes you end up just building the thing the HiPPO asks for … and that’s okay.
Now that you’ve gathered your stakeholders’ valuable input, I’d work behind the scenes to develop your recommended solution from first principles — like you usually would.
But, don’t take the easy route and go full steam ahead with your solution with no regard for the stakeholder’s proposed solution.
Instead, bring both options to the stakeholder (and other appropriate people) to discuss both concepts on their merits and choose a path forward. This reduces the chances of burning bridges and, most importantly, allows you to challenge their solution with a well-prepared alternative rather than just your opinion, past experience, or “best practices.”
Talking through the two options, head-to-head, ensures there wasn’t valuable context you weren’t able to gather initially. I’ve had many situations where this second discussion surfaced compelling evidence in support of the original idea and actually made it clear their original suggestion was the better solution.
This usually happens because the stakeholder has had time to think more deeply about their hunch. I haven’t found this happens often enough to merit just going with the proposed solution, though.
Make sure you move through this process quickly (usually 1-2 days and at most a week of elapsed time). Otherwise, you risk over-planning and wasting precious time (which won’t go down well with your stakeholder).
Senior stakeholders often have a wealth of information, experience, and context fueling their gut instinct – especially those at the frontline of sales and other market-facing roles.
Keep in mind, a product leader’s job isn’t to try to make the right decisions; it’s to make sure the right decisions get made.
This can be one of the trickiest parts of product management – pushing back against someone much more experienced and higher up the food chain. So be patient, consistent, and of course, respectful. Lean in, and soon enough, you’ll do well at this piece of the puzzle too.
No. 10. Invest in continuous value delivery
“Move fast and break things.”
When is this project going live? Can we get this thing launched any sooner? Do we know why this is taking so long?
Understandably, stakeholders want features to be delivered as quickly as possible. A feature shipped this month is better than next month, right? Sure, in a perfect world.
In reality, though, it’s our job as a product leader to convey the tradeoffs that come from maximizing velocity.
It’s all too easy to over-focus on moving quickly and end up shipping a ton of work that has a negligible impact on the end-user or the bottom line.
To avoid the common trap of shipping low-value “low-hanging fruit,” we have to ensure any conversation about velocity is met with a discussion of quality and value.
Smart prioritization is central to effective product management and is the best place to hedge against low-value velocity.
Similar to how the engineering teams have continuous integration – we want to have continuous value delivery.
We want to strive to deliver incremental value early and often.
To pull this off, we need to be very thoughtful about our prioritization process. It’s a tricky balance because there are tradeoffs everywhere. Should we ship these 5 medium-value things, or should we focus all our energy on a single high-value feature that’s really hard to build? How do we account for risk? What if our users don’t really get much value out of it?
Unfortunately, there’s no silver bullet. Not that I’ve ever come across, anyway.
This tip is about how you frame your approach, rather than a prioritization methodology. You’ll want to think carefully about your prioritization approach and treat it as a target for experimentation and optimization. Try different methods and see how your roadmap turns out. Think through the second and third-order impacts of those changes.
Be sure to bring your stakeholders along for the ride and develop a shared language of focusing on value-delivery rather than feature-delivery.
After all, what you measure tends to be what you maximize.
こちらもご覧ください
