throw out your spec—meet the problem page

If not a spec, what?

We all know—I don’t love a spec. I don’t like “requirements doc,” and I certainly do not like a waterfall process. That said, we product managers have to do, well, something, right? Probably. One of the key foundational activities of a product manager should be exploring and defending what should be prioritized and why. We can’t just say “no” and expect people to go along with it. That would be much too easy. Instead, we have to justify why certain things are more important than others.

A quick tangential aside on prioritization

One of my pet peeves with some leadership teams is their inability to effectively prioritize. You’ve probably seen this before—a list of 20 company priorities are presented, and 10 of them are P1s, 8 P2s, and 2 P3s. I just want to be clear here… this is not prioritization. This is basically saying “EVERYTHING IS EQUALLY IMPORTANT except for these other things that we will never have enough time to do”

This IS NOT helpful. By definition, you should have more P2s than P1s. P1 is the top of the pyramid. If the top of the pyramid is larger than the bottom, well, first of all, it isn’t much of a pyramid is it? And more importantly, the damned thing is going to topple over. Please don’t crush us with your inability to prioritize, dear leaders.

Enter Problem Pages

Since we know people won’t take our word for it, we need to put pen to proverbial paper and make the case. To do this, I find it very effective to create an internally-facing document for each general set of problems—a problem page. This document should articulate what problem set you’d like to address, for what audience, and why.

While this page should serve up data and facts, its purpose is also to persuade your internal audience that this is, in fact, the thing you should be working on. This is the time to get on your soapbox, to tug at heartstrings. You want a rallying cry that is as persuasive as Daenerys on her best day. You want for someone to read your words and jump up from their desk to CHARGE!

Note: This has never happened to me, but a girl can dream.

Anyway, I love to see this in a wiki format—whether that’s Confluence, Notion, or something similar. It should live in a place that is easy for engineers to find, product people to collaborate on, and internal stakeholders to engage with through comments. This is why I call it a “problem page” and not “problem document that will never change.”

I also want to note that what is covered below only pertains to the first part of the process. This same page will eventually be used to communicate possible solutions, eventual designs, and progress updates when actually in development. But, for the sake of brevity (who, me?) we’ll leave that for a future post.

Before you dig in

By the time you’re writing a problem page, you should already have done a ton of information gathering that led you to the point of creating the page. You shouldn’t need to do explicit research on the what, as that was likely the impetus for prioritizing the problem to begin with.

Before you even start, you should already roughly know the following:

• Who within your customer base is facing this challenge or would benefit from addressing this area

• What the problem is

• How the problem fits into your vision for the product

• How the opportunity fits into your team’s goals

A Word to Newbies

This is one of those things that gets way easier with practice and familiarity with your product area. If you’re new to being a PM or new to this concept, this is gonna suck a little bit. That’s ok. If you’re new to a particularly complex product, this is gonna suck a little bit. I promise you, though, that with time and experience this will be incredibly straight-forward.

If you are new to this concept, I’d highly recommend reading examples that already exist in the world. It might also help to start with a straw man of one of your problem areas, and then pair up with a more experienced PM to flesh it out. Engineers are always pairing up, but it’s just as useful for product managers. Talking these things out have a way of solidifying the reasoning in our heads.

---

So what’s in a Problem Page?

There is a basic, recommended structure to a problem page. The exact headings and sections aren’t worth losing sleep over, but you should make sure the content is there.

---

Overview

Description of Problem or Opportunity

This is an overview of the problem you’d like your team to solve.

It could be:

• A challenge current users are facing

• A capability deficit preventing new customers from adopting your product

• A usability issue preventing customers from finding / using / valuing something in your product

• An opportunity for some tangentially related problem space that isn’t represented in your current product

It should be:

• Phrased in terms of the challenge(s) you hope to tackle

It should NOT be:

• A specific feature

• A description of a solution to the problem

Target Audience

This might seem relatively self-explanatory, but it’s important to make this as broad or as scoped as is needed to really describe who you’re going to solve these problems on behalf of.

Things to consider

• If you have a multi-tiered product, is the problem space most important for a subset of tiers?

• Is there a certain size of customer? A certain captured revenue?

• Is this for existing customers, is it to encourage existing customers to choose a higher tier? Is this to attract new customers?

• Is this meant to impact/help an internal audience? (Very often this might be Support, Fraud, Trust & Safety, Billing, etc) 

Problem Prioritization

To really make a compelling argument about WHY you’re assigning priority to an issue, you may need to go back and gather more detailed information than you  needed when working on the overview section. I highly recommend you have as much explicit data as possible—both qualitative and quantitative.

Customer Impact (Qualitative!)

Get yourself some customer quotes. I’m talking first names of specific people. I want you to be able to write about Andrea who is trying to accomplish this task for her company. It’s a brutally manual process, and she dreads it every month. In the meantime, Wes from this other company is having nearly the exact same challenge.

You’ll want to discuss the FUD (fear, uncertainty, and doubt) of users in this area, and really tug on the heartstrings of your audience.

Supporting Data (Quantitative!)

Collect a variety of quantitative data, which could include any of the following:

• How much this impacts your customer

  • Hours spent

  • Money spent

  • Satisfaction levels

• How this issue impacts growth

  • Blocking deals?

  • Would unlock a market?

  • Contributing to churn?

• How this issue is placing burden on an internal team

  • Billing Team has to do x things manually each month

  • Customer Support is receiving x tickets per week

  • Trust & Safety spends x hours per week addressing this issue

• Don’t forget to quantify qualitative results if you have them!

  • NPS

  • Customer satisfaction

  • Task success

Company Goal Relevance

Time to bring it home. You’ve already tugged on heart strings to show why this is important to your target audience. You’ve queried the data warehouse to prove this is a meaningful pursuit. Now it’s time to relate it back to your team’s goals (which... hopefully roll up to your company’s goals…). How will this move your team toward its goals? How will this help achieve your company’s goals?

Now, this does not have to be a hard company metric type goal. A lot of us get caught up thinking this has to be a number like cohort retention rates or customer acquisition numbers or churn rates, but those are just a subset of the type of goals your team might be pursuing. Your goal might be to increase customer satisfaction, or to increase task success on a particular feature, or even to simply half an answer to a problem area that your competitors already address. (Though, never implement something just because your competitor has it. Perhaps this is a good topic for another post.)

The key here is to make a compelling argument that not only is this problem important to your customers, but it also helps the team move toward its goals.

---

Go forth and write

Let me know if you’ve ever tried something like this, and how it went for you. Do you have an example you’d be willing to share? Any helpful tips to share with your fellow PMs? Comment below! I may pull together some examples for a future post (with permission).

the holy tripod

tl;dr

1. At a minimum, a Lead PM, a Lead Designer, and a Lead Engineer should form a tripod that leads the product engineering team

2. The tripod should meet to establish agreed-upon responsibilities and communication patterns, starting from the generally accepted roles

3. No member of the tripod has the final say on everything, they’re like 3 co-equal branches of product government

4. Product is a team sport of solving a Rubik’s cube—you can’t change the constraints, so use prioritization and negotiate with one another in a collaborative manner.

---

Holy Tripod, Batman!

I couldn’t resist. But in all seriousness, the product tripod is a staple in my product belief system (PBS). I believe deeply that every product engineering team should have a tripod at its helm. Hopefully, by the end of this blog post, you’ll agree with me. Although why you wouldn’t just blindly follow me I’ll never understand. 🤷🏻‍♀️

Introducing: The Tripod

What are the key roles?

• Product Manager / Lead PM

• Product Designer / Lead Designer

• Engineering Manager / Team Lead

Why is it so important?

Successful products aren’t typically created from a single person’s mind, but rather through the art of collaboration between a diverse group of people. Even if your organization isn’t super, ahem, diverse (we’ll address that in a different post—I have thoughts y’all), you can achieve a degree of diversity of thought simply by ensuring these three roles are collectively leading the team.

Tripod+

Sometimes a product eng team tripod has even more legs than three (I’ve been known to call it a fivepod) if you’re one of the lucky teams to have access to one (or all) of these roles:

• Data Scientist

• User Researcher

• Program Manager

• QA Lead

It’s fairly common for these roles to either be non-existent in smaller companies, or to be shared among several product engineering teams. Depending on the demands on that person, you may find them being just as involved as the core tripod members, or you may need to prioritize the most important meetings and interactions.

The Tripod and Other Metaphors

Why do we call it a tripod?

What happens when you remove one leg of a tripod? Barring some sort of shenanigans, typically a tripod that becomes a bipod is a… laying-on-its-side-pod. A tripod cannot stand if any of its legs are out of commision. Such is the physics of a product engineering team. It requires a complete tripod to stand on its own three feet and perform to its full potential.

Is it a dictatorship, oligarchy, or democracy? (Dictatorship, right? The PM is clearly the dictator, right?)

Nope.

The tripod is both none of these and all of these. It both listens to / represents its people, but it is not a majority rule system.. It is both ruled by a group of people and gives individuals the power to make final decisions.

If you are working with a PM who’s acting like a dictator, they’re doing it wrong. Please refer them to me. If you are a PM and you’re acting like a dictator, please stop. And also come see me.

But I really, really want a political metaphor...

A much better metaphor is the system of checks and balances most Americans will be familiar with as represented by our three co-equal branches of government. A group of three working toward the greater whole, but with specific, individual areas of responsibility.

Roles & Responsibilities

Why are they doing what is clearly MY job?

The responsibilities of the tripod overlap by design. This can often cause some consternation—someone’s always convinced someone else is usurping their job—but it’s important to understand the primary roles of each member of the tripod as well as the overlapping contributions they may make.

Things I’ve thought or said out loud (to people not in my tripod):

“I just feel like he’s trying to do my job.”

“But I’m supposed to run the sketch sessions!”

“I just need us to get this thing done… AGGGHHHHH”

“But I can’t let them design a solution without my participation!”

Yeah... don’t be me.

What are the definitely locked down and set in stone responsibilities?

Not so fast, rule-follower! While I like to believe stubbornly that these roles are super widely defined and acknowledged, the truth is we are all unique humans. (I’m here for the hot takes.) While there is a general guideline for who is responsible for what, each of us brings certain strengths, interests, and areas of expertise to our tripods.

The lines between each role are bendy… flexible, if you will. They can flex to conform to your unique tripod. The only absolute constant is that you must collectively discuss and define your roles when forming a new tripod. Like any relationship, communication is everything.

What are the more-or-less generally accepted hand-wavey responsibilities?

Product Lead

• The expert in target customer needs/problems/opportunities

• The main representative of company goals back into the team

• The main representative of the tripod out to the rest of the company and customers

• The final decision-maker on overall priorities / and or scoping decisions as a result of collaborating with the other leads

Design Lead

• The expert in user experience personas for the customer base

• The owner of the overall user experience and design aesthetic for the product

• The main representative of company design systems back into the team

• The final decision-maker on implemented designs

Engineering Lead

• The expert in the technical lay-of-the-land for the product

• The main representative of technical capabilities, constraints, company maintenance, and technical debt surrounding the product area

• The final decision-maker on resourcing and structuring implementation within the product engineering team

It’s easy to say the designer has the final decision on designs and the engineering lead has the final decision on timeline and implementation and the lead PM has the final decision on scope, but it’s much more complicated to piece this together in practice.

Tripod Decision Making as a Rubiks Cube (because we needed another metaphor)

Look, this stuff isn’t simple, so I’m just putting it all out there. 

Here’s a common situation that comes up time and time again in product:

-------------------------------------

DESIGN LEAD: Here’s the best possible
user experience

ENG LEAD: Cool, that’ll take us about
6 months.

LEAD PM: Nope. Try again.

DESIGN LEAD: Ok fine we could
cut this piece or phase it in later.

ENG LEAD: That doesn’t really help
us much… PM?

LEAD PM: We absolutely have to have this
piece and this piece, but that piece we could
probably punt on. What do you both think?

[debate for awhile, and comes to shared conclusions]

DESIGN LEAD: Cool here’s a new
design.

ENG LEAD: Would you be open to
changing this design element in this
way? It would save us a ton of effort.

DESIGN LEAD: Ahh, yeah here’s a
revised design.

ENG LEAD: Cool.

LEAD PM: Cool.

DESIGN LEAD: Cool.

ENGINEERS: WAAAAAHHHHHH.
(jk jk)

-------------------------------------

The Rubiks cube represents all of the constraints that the team is working with, and you, as the tripod, have to solve the puzzle together, as a team.

Imagine that your cube has these six sides:

1. Problems to be solved

2. Resource constraints

3. User experience standards

4. Technical constraints

5. Time constraints

6. Prioritization

Now, you may have noticed that “prioritization” seems like a bogus side, and you would be correct. It’s actually a placeholder side. Constraints are unchangeable, but using prioritization we can, in fact, move constraints around to find the optimal product.

Doesn’t fit into a totally important (read: arbitrary) timeline your company has? Ok, turn some rows. Now it fits in the timeline but doesn’t have an acceptable user experience? Great, adjust some columns. Keep working that cube as a team until you’ve got it solved!

The responsibilities of The Tripod

Obviously each member has their own responsibilities within the tripod, but the tripod itself has responsibilities as well.

Ok, what do they do?

• Represent a shared front to the engineers on the team

• Discuss and debate team priorities on a regular basis

• Discuss team performance, concerns, and develop plans for how to address any issues

• Cover for one another in case of illness / emergency / babies coming early / whatever

• When in doubt, unblock the engineers

• Collectively take ownership of the goals and results of the team

• Challenge each other in a constructive way

How do we do that?

You may find that you need to meet as a tripod on a structure basis (once a week, once a sprint, whatever) in order to stay aligned with one another. Alternatively, you may find that simply working next to each other and chatting in ad-hoc ways may work for you. Either way, it should be discussed and explicitly chosen.

paying off tech debt -OR- my PM is scary

I’m an engineer, and I am told to work on “paying off tech debt”,  but I think if I do that it’s going to make my product manager mad. @eboyle what do I do?

Dear Engineer,

My advice is to get a new PM. Nah, just kidding. (A little. Mostly. Kind of.)

Questions like these are hard, because they’re not directly within your control. I do believe—quite strongly—that no product manager worth their salt will ever flat-out reject talking about the work you need to do to clean up tech debt. A good product manager will ask questions, and work with you (or your engineering manager) to determine how to layer tech debt work into ongoing product work.

Weighing the options

Here are some questions I would ask as a PM:

1. What’s the scope of tech debt you plan to address?

2. How urgent is this debt? If we don’t do something, will we have problems in 2 weeks? 2 months? A year?

3. Does this tech debt directly impact any of the product areas we have plans to touch?

4. How does this stack against other tech debt within our domain?

5. How might this impact our existing goals? Will we not be able to address [problem y] if we pay down [tech debt x]?

6. Can we divide this work up into smaller chunks?

Now, note that I don’t ask any of these questions because I don’t think paying down tech debt in important. But rather, I think it’s just as important as product feature work, and prioritizing feature work goes through a similar gauntlet of questions. The main difference is that you, the engineer, know way more about this problem set than me, the PM. So be a little patient and get me up to speed.

At this point, it really becomes a joint decision between the engineering and product managers. Both are responsible for weighing the trade-offs and coming to a reasonable compromise.

Build tech debt pay-down into your team processes

Every product or product area is unique when it comes to how much time needs to be spent working on features, updating designs ( design debt is real, y’all), or paying down tech debt. A healthy product tripod (engineering manager + product manager + lead designer) should decide on the default weight of tech debt for their ownership area. 

For example, if your product is fairly healthy and has a steady (but not overly aggressive) feature release cycle, a good rule of thumb is to dedicate 20% of engineering resources to paying down tech debt. This might mean that you always have one or two engineers working on tech debt in a rotation, or it might mean everyone is responsible for spending two days a sprint paying down tech debt.

A product area that isn’t seeing a lot of new product development, on the other hand, may have a higher rate of tech debt management. A feature in startup growth mode? Probably not going to be working on much tech debt.

Ok but I have a leaning tower of Pisa-code

Are things… leaning? Does it feel like you’re playing a very technical game of Jenga? Are you worried that working on the next feature will start crumbling the whole damned thing? Cool, 20% is probably not going to work for you. This is a perfect time for the tripod to reassess priorities and put the majority of focus on paying down the debt before it becomes a 4-alarm fire.

Please don’t let it become a 4-alarm fire. Don’t let your PM let it become a 4-alarm fire. But also be careful of how many times you play that card. If you treat everything as urgent, there’s a good chance you’ll start losing credibility with the PM. If it can honestly wait a year, say that. If it could really use an overhaul but really only this one piece needs to be done soon, say that. If it’s going to hell in a hand basket, for heaven’s sake say that too.

What even is tech debt?

Spoiler: almost everything in this post are questions I ask when I’m interviewing engineering manager candidates. I worry less about the answers, and more about how much thought has gone into tech debt as a concept, how much experience has gone into processes, and whether those views are nuanced. Let’s be honest, this is all just a pile of nuance.

So, here’s my take on what counts as tech debt. But again… nuance. Hand wavey. Also some things may fit into more than one of these categories.

• Backend performance issues (think: long-running queries, database design issues, capacity issues)

• Frontend performance issues (think: insanely large images, network chattiness, non-incremental loading)

• Spaghetti code (we didn’t know where this was going to go when we first built it, but now we do and this is only going to get worse)

• “Building feature xyz will take us 10 years and a million bribes in the form of cookies if we don’t redo this” things

• “I-don’t-understand-but-trust-that-you-do” things

• “Starting to address this now will prepare us for that thing we wanna do next year” things

• Bugs. Yes. It’s true. Bugs happen. WE WILL SMASH THEM. But this is not, in the classic sense, tech debt.

You, too, can own a backlog

In my (in)famous guide to writing stories, I decree the following:

Thou shalt have all stories, chores, and bugs related to a product initiative in a single backlog

Exception: Tech debt or tech-only projects may have a separate technical backlog

This is probably a great time to talk about that exception. I strongly advocate for having a backlog dedicated to non-user-facing-bug tech debt. There’s already enough ordered chaos in the main backlog—there’s really no need to complicated matters further by adding in tech debt stories that I (or your product manager) may or may not understand—and I say this as a fairly technical PM.

There are several key advantages to having a separate tech debt backlog, other than saving my eyeballs from confusing stories:

• The engineers can manage this backlog independent from product and design

• Having a single list of tech debt allows the engineering manager and engineering team to prioritize tech debt amongst other tech debt

• Whether everyone spends a percentage of the sprint working on tech debt, or whether there’s a rotating spot on the team, everyone has a single prioritized place to know what to work on next

• Having actual stories can help keep engineers on task / prevent y’all from going down a rabbit hole of code optimization that I know you all fantasize about. I know you. Do not doubt me.

• Having actual stories means engineers can pull them into a sprint, so that there’s no magical work happening that’s not being tracked against your velocity

But Erin, I thought tech debt should not be a thing that’s estimated!

Did I say that? I actually don’t think I said that, although… maybe I should’ve.

Honestly, whether to point or not to point tech debt, that is the question for your whole scrum team. Many teams decide to not point tech debt. Some teams decide to point-only-as-an-effort-box tech debt stories. It kind of doesn’t matter to me. As long as you pick one method and stick with it, it all can work.

No matter the method and whether there are points on tech debt stories, dragging them into your sprint will help your PM understand what you’re working on and where your time is going.

NOT BECAUSE THEY WANT TO MICRO-MANAGE YOU.

Seriously we have enough to do. We have no interest in micro-managing you. But we often have to set expectations and communicate progress to stakeholders and partners within the company. The more we can do that without having to bug you about what you’re doing, the happier we both are.

It’s ok to make your PM a little mad. Sometimes.

A product-engineering team is a lot like a system of checks and balances. It can feel like PMs are the executive, legislative, and judicial branches all in one, but it’s not actually true. Healthy teams should have disagreements. That doesn’t mean you don’t treat each other with respect… you absolutely treat each other as humans. And you also should push each other. Our strength as a team comes from being able to challenge one another because we all have different backgrounds, strengths, and perspectives.

when it comes to Product managers being mad… it’s all relative.

tl;dr

So, that’s what I’d do. Make sure that you, as a team, talk about how to handle ongoing tech debt pay-down vs one-off or project-level pay-down. Be prepared to answer your PM’s questions about what you’re proposing. Prioritize tech debt within a backlog. And, you know… irritate your PM once in awhile. Tell them I gave you permission.

Until next time,
eboyle

---

Curious about something
I haven’t covered?

Just Ask

eboyle's guide to writing user stories

Rules:

• Thou shalt have a shared backlog with all engineers on your pod

• Thou shalt have all stories, chores, and bugs related to a product initiative in a single backlog

  • Exception: Tech debt or tech-only projects may have a separate technical backlog

---

STORIES

What does a story look like?

Name

As a [persona] doing [x], I can [y]

Description

Give a bit of context of why this story is important to the persona. If this is a part of a large set of stories, reference where it fits into the larger picture

UX/UI

[link to invision]

embedded image when possible

Acceptance Criteria

1. When x is clicked, y happens

2. Edge case expected behavior

What belongs in Acceptance Criteria?

I mean. This isn’t gospel… but this is the law according to eboyle: Any action or interface element that needs to be present, conditionally present, or change through the course of the story should have at least one acceptance criteria. Basically if an engineer is going to have to know the answer in order to build it, it should probably be in there.

Let’s take a look at some examples:

EXAMPLE 1:

As a Creator viewing PRM, I can filter by charge status (because this helps me do x)

Description

We want to add a new drop-down filter! The filter's label should be "Charge status," and it should list the "friendly" charge status labels (paid, pending, refunded, declined, deleted, fraud, other).

UX/UI

[link to invision]

Acceptance Criteria

1. A new single-choice drop-down filter is present to the right of the existing filters

2. The default option is "All charge statuses"

3. When a charge status is selected, the list should refresh automatically

4. If "Reset" is clicked, the charge status filter should clear

EXAMPLE 2:

As a Creator viewing PRM, I can sort the list by pledge value (because this helps me do x)

Description

By default, the list of Patrons is sorted in alphabetical order. We want to add the option to filter by a few other columns as well. In this story, we'll let creators sort by the current pledge value of patrons.

UX/UI

[link to invision]

Acceptance Criteria

1. When a creator mouses over the "Pledge" column header, the cursor becomes the hand (shows it's clickable)

2. When a creator clicks on the "Pledge" column header, and no previous sort was set on Pledge, the list is sorted by pledge value ascending

3. When a creator clicks on the "Pledge" column header, and the list was already sorted by Pledge asc, the list becomes sorted by pledge value desc

4. When a creator clicks on the "Pledge" column header, and the list was already sorted by Pledge desc, the list becomes sorted by pledge value asc

5. When the list is being sorted by Pledge asc, an upward arrow is displayed to the right of the column header

6. When the list is being sorted by Pledge desc, a downward arrow is displayed to the right of the column header

7. When the list is no longer sorted by Pledge, the arrow is removed

8. Upon sort, you go back to page 1

What does an API story look like?

Pretty similar, but with a few tweaks tailored to the real need. If you don’t feel comfortable writing this as a PM, that’s cool - partner with your Scrum Conductor!

Name

As an API Consumer, I can [x]

Description

Give a bit of context of why this story is important to the persona. If this is a part of a large set of stories, reference where it fits into the larger picture

Permissions

Who should have access to this endpoint? Just the creator? Patrons and creators? Patron only?

Inputs

What parameters should this endpoint accept? An ID? an array of IDs? Which of the inputs are required? Will you allow any side loading?

Outputs

What data should be returned when this endpoint is hit?

Acceptance Criteria

1.

---

EPICS

What’s an epic

Text book definition: 

(https://www.atlassian.com/agile/delivery-vehicles)

An epic is a large body of work that can be broken down into a number of smaller stories. For example, performance-related work in a release. An epic can span more than one project, if multiple projects are included in the board to which the epic belongs.

Erin’s definition:

A way for a PM to keep their stories organized so as to stay relatively sane. Usually they align to some chunk of work that delivers value to a customer. I always prioritize within the epics, rather than try to prioritize the whole damned backlog. It’s just too much.

Do I have to use epics?

Absolutely not. If you’re working with only 2-3 engineers and you really only have a small scope of work, there’s no need for epics. Epics are more useful with larger teams who are working on multiple projects at once.

---

BREAKING IT DOWN

User stories should be granular enough that an engineer can complete the story within a day, generally speaking. Each team probably has their own point system, and each team should also have a threshold for pointing a story. Above that threshold, and you’ll need to split the story apart.

Most full-stack features will likely need some backend stories (database schemas, etc), some API stories (CRUD endpoints, for example), and frontend stories. Generally speaking, it’s great to keep these things separate.

Backend Stories

I’ll sometimes stub out the real technical work here (like creating a schema, etc), but mostly… I leave this up to the backend engineers to write.

API Stories

I like to write these out after getting a better understanding of what’s needed from the front end. What information will the page or state of your page need to be provided? In the case of a table or list feature, this comes in the form of which columns I need to display, or what information I need to be able to create or modify within the table.

Frontend Stories

To me, these are the easiest stories to break down (because I’m a visual person). I like to start with the largest, and least specific detail possible, and work my way down to various elements on a page.

For a typical “list” or “table” feature, I’d usually break it down like this:

• The page exists, with the title

• Data is displaying in an unformatted table (and here are the columns)

• Data is displaying in a formatted table

• Pagination controls are present

• Hovering over a row does x

• Button y is present, and when clicked does z

---

ESTIMATING

Are you an engineer? Great. You should be estimating. Are you a PM? Stop. Go get an engineer.

How should you estimate?

It’s cool for all engineering teams to do pointing in a slightly different way. However, there are definitely some best practices in how to think about estimates. Estimates should not reflect the amount of time it will take you to complete a task, but rather the relatively complexity of one task as compared to another. Fibonacci, as it turns out, is great for this.

Let’s say we have the following 5 stories in the backlog:

1. Change the description on Page x

2. Create a new modal that contains a list of data

3. Add a button on Page x that pops a modal

4. Create a new component to manage sorting for a table

A string change is probably… 1 point. If even. Is creating a new modal that hits and endpoint and displays data more or less complex than the string change? Sounds more complex. Great. Now, when you thinking about adding the button in comparison to the modal, is it less complex, or more complex? Probably a little less. And finally, how does the complexity of a new sort component compare?

At the end, you might say that the tasks, in order from least complex to most complex, are task 1, task 3, task 2, task 4.

To assign actual points, though, you have to go a step further. Is a button TWICE as complex as a string? Then 2 points is fine. Is it actually more than twice as complex? Maybe 3 points is a better estimate. The other thing to keep in mind is unknowns. The less certain you are about what it will take to fulfill any given task, the higher the point value you should give it.

After some time, the team should coalesce around roughly what points makes sense for your team, and have anecdotes like, “well a 3 point story feels like x, but a 5 point story feels like y.”

Why should you estimate?

A couple reasons. First, it should help you understand how much you might be able to accomplish in a week.

As engineers, estimates will inform how you think about milestones over time. At some point, you’ll have to say, “we think we might be done with x chunk of work by z date.” Understanding (over time) your point-based velocity will give you a more accurate prediction of this.

As a PM, estimates will help you understand the relative complexity of what may seem like small features, giving you the ability to prioritize more effectively. Is this 5 point story actually providing much more value than this other 2 point story? If not, maybe it’s time to scrap or de-prioritize that 5-pointer.

What even is an estimate?

It’s just that, an estimate. It is not a deadline, it is not a promise or guarantee, and it will often be wrong. It should also more often be directionally correct, and help us get better at things like milestones over time, because it’s a way for us to start quantifying and grasping something that is largely, let’s face it, unknown.

How much time will it take you to solve this puzzle?

Really hard question to answer, if you’ve never solved the puzzle.

How much time will it take you to solve this puzzle, given that it took you x minutes to solve this other puzzle that was similarly complex?

Easier to answer. But still very inexact.

Also, keep in mind that as a product organization we are AGILE. That means our priorities might change, or we might learn something new, or some unexpected thing will come up that will throw our milestone dates RIGHT out the window, even if we because wicked good at estimating with Fibonacci points to begin with.

tl;dr estimates are a tool, and nothing more

---

BACKLOGS

How much backlog is the right amount?

In general, the hand wavey rule on this (no, not just my rule, it’s a real thing) is about 2 weeks. In other words, you should always have 2 weeks of granular, fleshed-out stories for your team.

Can I have more?

I mean, of course. But, I’d encourage you to leave stories that won’t be addressed for >2 weeks at a higher level, like an epic.

What about all the ideas I don’t want to lose track of?

First of all, skeptical face. Second of all, keep an ideas backlog in some other place for you, as a PM, personally.

Also, I break these rules all the time, and should probably go blow really old stories away, because real talk we’re never going to get to them. And if/when we do we won’t remember there’s already a story.