Tip
If you only take away one thing from this document, it should be this:
Write a "press release" before you start any work.
The only thing that should be a ticket is something that is worthy of a press release. Otherwise, it's likely just a subtask of a larger ticket, and should be tracked as such.
This makes it clear to all participants the "story" of what we are trying to accomplish, and the benefits unlocked for our customers. It also makes it easier to understand and to prioritize our work, and to understand platform "features" we've shipped.
This also makes it easier to understand the "why" of our work, and encourages ownership and accountability for specific outcomes in the larger system and experience we are striving to build and maintain.
A good example of a ticket:
"Users will now be able to build and deploy Docker images"
Not a good ticket:
"Add Dockerfile support to our build system"
Start with the press release, before creating any tickets. Writing a press release upfront forces you to think about the "why" of your work, and to understand the benefits from the perspective of your customers.
The press release is an instantly shareable document, whether sharing with the team or with architects for collaboration, with customers for feedback, or with leadership for buy-in and storytelling. It can be used to align everyone on the "why" of the work, and to get feedback and buy-in from all stakeholders.
Tickets with clear goals, in-depth guidance where needed, and accessible links are all important for both humans and AIs to understand a ticket and gain the correct context.
Feeding the press release into an AI can enable you to quickly generate a more detailed plan, including subtasks, acceptance criteria, and even code snippets. This can help you to refine your ideas and to ensure that you have thought through all aspects of the work before you start. It also makes it easy to completely change the plan and test different approaches, without the overhead of having to rewrite the press release yourself every time.
Make sure your press release is at least 2-3 paragraphs of thoughtful writing, otherwise the AI is likely to generate a tangential plan that doesn't align with your vision. The more detail you can provide in the press release, the better the AI will be able to generate a plan that aligns with your vision, making sure you don't commit to building things that don't actually solve the problem you're trying to solve, or that don't actually deliver the benefits you're trying to deliver.
In a world where generating text is cheap, the critical thinking in drafting the initial press release is where humans can add the most value.
You don't need to get buy-in from everyone before you start writing a ticket. Just start with the press release, and share it with the relevant stakeholders as you go. This can help you to get feedback and buy-in from the right people at the right time, without having to wait for everyone to be on board before you start.
You don't need everyone to commit to this workflow. This can be used to improve the quality of the tickets that you write, with the accidental benefit of making it easier for others to understand and to collaborate with you on your work, and for you to demo and share it with others.
We also frequently forget things. Treat your press releases as a living history of your thinking and your work, that you can refer back to when you need to remember why you made certain decisions, or to share the "why" of your work with others.
- Does the ticket have a clear goal that can be easily understood by both humans and AIs?
- Does the ticket have a press release that clearly articulates the "why" of the work, and the benefits for our customers?
- Does the ticket have a detailed plan that includes subtasks, acceptance criteria, and any necessary links to documentation or resources?
- Has the ticket been reviewed and approved by all relevant stakeholders, including architects, customers, and leadership?
This knocks out your ticket writing, design, planning, stakeholder communication, demo, project management, documentation, and review process all in one go. Even if you don't commit to the work outlined in the ticket, you'll have a commented-on and reveiewed press release that has either been accepted, redlined, or rejected by your stakeholders and customers, which is a valuable artifact in and of itself. You can then use that press release to guide your work, or to remember or refer to why previous work was not attempted.
This also reduces the ceremonies that take the most of your time (design sessions, meetings, approvals, chats, emails), and replaces them with a single artifact and a process around the evolution and approval of that artifact.