Product process

[Sean Colsen]

In reviewing tomorrow’s agenda items, I noticed that Kriti added a “Product process” topic to follow up on a question that I raised recently. Thanks! This email is to seed that discussion with some thoughts ahead of time.

I mentioned two distinct processes that I want us to improve:

1. Our “approval process”: This is where we decide if we want to do something specified in a ticket. This process usually moves a ticket from status: draft to status: ready.

2. Our “prioritization process”: This is where we decide when to do something. This process usually alters the milestone on a ticket, slating it to be completed for an upcoming release.

Generally, I think our prioritization process could use some honing, but I’d say it’s actually working okay and might not warrant a team-wide discussion at this point.

The approval process is what I want to discuss the most, because our process here seems to be less specified than others.

Here are some examples of “draft” tickets which (as I see it) are currently blocked on this “approval” process. If we can figure out how to approve tickets like this, then in many cases we could open them up to community contributors to work on. Or, if we can figure out how to “reject” them, then we can reduce our queue while maintaining an archival log of our decision process.

• Allow Typing Into Cells Once Highlighted
• Make navigation header behave more consistently
• Remove “Records will be repositioned on refresh” message
• Be explicit when displaying empty strings as cell values

This is my main question:

• How do I determine which team members need to approve a ticket in order for the ticket as a whole to be considered approved?

In an ideal world we might be able to codify a rubric that allows all team members to reliably and independently draw the same conclusions to that question. But I’m not seeing a simple path to such a rubric. For efficiency’s sake, we ought to avoid requiring every team member to approve every ticket. But identifying a subset of our team to approve all such tickets seems to risk omitting members who hold strong opinions or background knowledge on particular areas of the product.

This conundrum reminds me of this HN thread from last week: The product manager role is a mistake. The article is, in my opinion, not very good. It makes some interesting points, but mostly seems to lament a dysfunctional dynamic present on some teams while failing to give pragmatic advice for better alternatives. I came away from the article perplexed. But after reading the HN comments, I began to reflect on the challenges we have in our team making product decisions, and many of the comments refuting the article really began to resonate with me. This is all to say: I think we need some clarity within our team about who is responsible for these ticket “approval” decisions. For example, hypothetically our answer could be: “Kriti (and only Kriti) is responsible for approving draft tickets”. That would be fine with me. If we had that kind of clarity, then I would assign these “draft” tickets to her for her to review and approve. Then we could move them forward by approving (or closing) them. What’s difficult for me currently is our lack of clarity on the process. Interestingly, I see that difficulty reflected in many of those HN comments arguing (against the article) that a “product manager” role is crucial for their teams.

​