How long will it take to get this ticket done?
How long will it take to get this ticket done?
"Everything Starts Out Looking Like a Toy" #113
Hi, I’m Greg 👋! I write essays on product development. Some key topics for me are system “handshakes”, the expectations for workflow, and the jobs we expect data to do. This all started when I tried to define What is Data Operations?
This week’s toy: A LEGO build that plays the drums. (Really.) It’s fun to see the combination of a digital idea (a timeline that plays back beats) with a system that can hit those beats. Call it a 21st-century version of the player piano, and it’s pretty neat. Edition 113 of this newsletter is here - it’s October 3, 2022.
The Big Idea
A short long-form essay about data things
⚙️ How long will it take to get this ticket done?
It’s a frequent question for anyone who works in a product organization: how long will it take to get this done? Rather than replying “it depends”, it’s helpful to give the requester an idea of the process a request traverses to end up being something that “gets done.” This won’t stop the question, of course; and it will spark a more fruitful discussion where you can talk about where things are rather than an imaginary delivery calendar.
Here’s an example of a process to follow to evaluate requests, ensure that bugs and escalations are handled, and build a pipeline of work ready to be completed and evaluated by developers. It’s not foolproof – there’s no process that survives first contact with customers – and it’s a good place to start in defining the workflow of stories and issues through your organization.
Is it a critical, work-stopping problem?
Whenever you start a basic triage, it’s important to figure out whether this is a widespread or critical problem. If this is true, “when’s it going to be done” takes on a special case as you ought to be all hands on deck to solve the problem. If you think you’re facing a critical problem, make sure to have at least one other person test that they see the same thing. After confirming, feel free to leap into action.
Most of the time the kind of issues that will come up in the “so, when’s it going to be done” conversation group this way:
A new thing the customer has asked for
A new thing that’s come up in conversation
A brand new idea from a team member
Whether it’s a net new idea or a tweak to an existing feature, it’s always important to know the specific improvement in the context of the user’s request. What were they trying to do? What did they see on their screen or in their other process? The more information you get, the easier it will be to understand the request. (If you’re getting a blank stare when you explain what’s going on, it will help to add some context.)
Is this a request a “Good Idea”?
All of this initial discussion will serve to label your issue and determine if it is a Good Idea. This is, of course, a loaded judgment. Some of the ideas that will show up in this process are not ideas that you intend to follow through on. There are also ideas that may not seem fully formed that get through the ideation process and turn out to be pretty good. There needs to be a process or a general standard to indicate whether ideas are good because it costs money and time to process these ideas to get them closer to development.
“Good ideas” tend to be aligned with:
increasing the ability of the ideal customer to use your software, particularly in a way that increases the usability and simplicity of getting stuff done
fixing an obvious deficiency that stops the user from doing something intuitive
a novel capability currently missing from the product that is aligned with the types of problems users want to solve
The definition of a good idea will definitely shift over time, though it ought to be related to the basic DNA of the product and should make sense when you compare it to existing features in the product.
Is it a good idea that we are already working on?
If this idea is good, we might already be working on it. In a product or success org, it would be nice to think we don’t create duplicates. But this sometimes happens. When you find a duplicate, it’s important to compare the new idea to the one already in the process. You might find new wrinkles in a feature or an important nuance that needs to be included.
And each time you review an existing idea, ask yourself whether we should work on this idea over another idea. If an idea or request comes up often, it’s a sign that users are encountering the same problem repeatedly. A product enhancement might not be the only way to solve this issue. Test your assumptions and ask if there’s another way to achieve the goal. (Pro tip: search your list of issues and you might find things that look familiar. Your team will thank you.)
When you are setting the internal priority, keep in mind that there is probably another solution to the issue you are raising. Workarounds usually exist to a customer request. They are often complicated, brittle, and hard to complete. And they can be the best option for right now. If there’s no workaround, the idea is good, and it sounds like the kind of idea we should be working on, it’s time to move it to the next stage.
Note: an idea can be great and it may not take precedence over another thing we’re working on simply because we’re trying to move an entire body of work into a stage where it can be worked on by a developer.
Let’s write a story
Once you have solidified the problem and the need, this information needs to written out in a formal way to ensure that the rest of the team knows what to build. A user story is a form of writing out the requirement to let us know the critical elements of what to build when we are discussing a solution to a problem. We want to answer questions like:
Which user or kind of user are we building this for?
What is the expected behavior, including the entry and exit behavior?
What kinds of actions trigger changes, and are they directed by a user or by an API or a different system?
Is this a reversible change, or does it trigger a change that cannot be undone?
What typical error conditions might occur and how should the system respond?
How will we measure the usage of this feature?
How does this feature fit with other systems that we have in place?
A successful story will answer many of the questions an implementer will have about building the experience it suggests. It will identify open questions that come up during the discussion. And stories will not be complete without visual illustrations that show what to build next.
What does it look like in our mind’s eye?
Stories alone usually don’t let us know what to build. A picture is worth (at least) 1000 words. In the context of a feature story there are a few different kinds of illustrations that will help in the review process:
a basic illustration, showing the labels and basic flow of the feature. This is necessary for having a discussion and initial estimation.
a pixel-perfect rendering of the feature as it would show up in the product. This is expensive and should be done when you’re sure what to build as the last gate to making items ready for review.
Detailed illustrations along with user stories are the key to pitching a feature the rest of the team can evaluate and help you determine if the feature is ready for development. Because the stories and the pictures don’t always translate into a package that’s completed. When this happens, keep doing this loop until you answer the relevant questions and are ready to go.
Ready for development
Features that have been reviewed, have well-maintained stories, and have practical illustrations are ready for developers to pick them up and work. That tells you what you could work on. It doesn’t tell you the order or the scope of what you should be working on. That’s because the build process is dynamic. It’s related to the market, your roadmap, and the way your customers want to use your product. “Ready for development” is a state of mind where you continue to stack work that is relevant, aligned, and detailed enough to deliver results.
What’s the takeaway? Getting work done is a continuous process. Following a process to take in new work, develop it so that it can get reviewed, and stack that work in a development pipeline aids in creating a productive backlog of work. It also helps you answer the question in your organization of “how long will it take to get this done.”
Links for Reading and Sharing
These are links that caught my 👀
1/ Team > Star - high performing teams are created through process, not automatically. This interesting piece of research demonstrates that the effect of team building to produce high-quality team results works across industries and fields.
I also ran into this piece by Vicki Boykis on The Team as a System that reinforces this idea of team performance. The team > the individual when it comes to producing outsized results.
2/ Dataviz Design as a Service - Building reusable components for chart design is a tall order. You need to consider different chart types, data volumes, and data types. That’s why this design toolkit from the WHO is a treat for anyone who likes to think about data visualization. It describes the fonts, visual treatment, and suggested labeling for data series in different kinds of charts.
3/ How do you linear regression? - This explainer is a great primer for linear regression. Using a few examples that you can update interactively, it shows you the relationships between variables in an equation. You might even learn something (I did.)
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon