7 artifacts for effective product development (incl. templates) — part 2
This is the second of a two-part article. You can read the first part here.
In the first part of this article, I introduced the need for product artifacts that together with a defined rhythm (aka a set of ceremonies) can help you set up an effective product development system.
To make the system building a little easier I’ve introduced the seven artifacts that I considered key in the different product development systems that I built in the past. I called them ‘the product artifact stack’👇.
The first two artifacts (which I discussed in part one) set the base for how product development is done collaboratively in a squad or the entire product development organization. The following five artifacts (which I’ll discuss below) help to define and coordinate what a squad or product development organization is working on at different levels of execution.
The 5 artifacts that help define and coordinate what is worked on at different levels of execution
The five artifacts described below ensure that all the work of a product department ladders up to the organization’s ultimate goals. As a whole, they provide a shared decision-making framework that helps to stay aligned within and between squads. Better alignment, in turn, leads to better and faster product decisions.
Artifact 3: product vision and strategy
Every product-led company needs a product vision and strategy. The product vision describes the future you want to create. The product strategy describes your path toward that vision. The artifacts outlining vision and strategy and the way how they are deployed are key aspects of a well-oiled product development system.
I’ve worked with numerous formats for a vision and strategy artifact in the past ranging from a product vision as a video (we called it a ‘visiontype’) to a written two-pager as the strategy.
I don’t have a template for this but would always point to either Roman Pichler’s product vision board or Melissa Perry’s product strategy canvas to get started.
Artifact 4: outcome-driven roadmap
A roadmap breaks down the strategy defined above into clear outcomes and themes that you want to achieve and work on in a given period, e.g. within a quarter. It’s a high-level prioritization and planning tool.
There are a ton of software tools that help create and visualize such a roadmap (e.g. Productplan or ProductBoard). If you don’t have the budget, or if those tools don’t fit your needs, you need to develop your own roadmap template.
At Saiga, we developed a quarterly product roadmap view that visualized how our key strategic pillars, targets (in our case Objective and Key Results — OKRs), and initiatives work together 👇.
Here’s how to read this roadmap:
- The strategic product pillars (in yellow) and company OKRs (in white) are listed at the top. They guide the product development department’s OKRs (in green) which are listed beneath.
- Each key result is then assigned to one or two squads. Instead of putting things on a timeline (that is likely to be unrealistic), the key results for each squad are ordered by priority (numbered circles).
- When reviewing progress on the key results (at Saiga we did this once per month as a department), emojis are used to signal success.
- Beneath each KR are the initiatives being worked on right now, or that are already completed (in purple). Emojis signal the high-level state of an initiative (in delivery, in discovery, shipped).
- Initiatives that might positively affect the KR and might be pulled into discovery are then listed as initiative candidates (in blue).
- Finally, and this is an important aspect that should not be missed, we then list all those initiatives that we will not work on (= non-candidates in pink). Either because they won’t impact KRs, are out of scope, or are not in line with our strategic pillars.
Based on my experience, it’s helpful to fill such a roadmap view with life by combining a top-down and a bottom-up approach. At Saiga, we would run a workshop that started with looking at the strategic product pillars and company OKRs. Next, we would brainstorm and prioritize initiatives that fit the strategic pillars and company OKRs. Only then, we would cluster initiatives and formulate suitable OKRs for the product development department.
Note: we used this template at Saiga when we were a fairly small product-engineering-design organization of only three squads. It’ll probably be hard to use this format, with the same level of detail, for much bigger organizations.
Feel free to make use of this Miro template.
Artifact 5: product pipeline for initiative documentation
The above roadmap gives an overview of the key targets and related initiatives. It helps to prioritize and track progress at a high level. What it doesn’t show are the initiatives’ relevant details and the more granular progress made on each initiative.
To document the specifics at the initiative level, you can use something that we at Saiga called the ‘product pipeline’.
The product pipeline is a board that lists all ongoing initiatives 👇. The stages (columns) in the board match the stages outlined in the product development process described in the first part of this article.
Each in-progress initiative that a squad is working on has its own tile on the board. A tile is the single source of truth that records the why and how of an initiative. A new tile can be created from a template that guides the squad along the questions that should be answered throughout the product development work for this initiative 👇.
Such a document would be defined by some as a product requirement document (PRD). I’m careful with this terminology as it stems from the waterfall world where each and every requirement was listed by a business person before being handed over to design and engineering. In our case, the resulting document is less important than the process of defining and creating it collaboratively as a cross-functional squad. The document lists both the final concept requirements and all the alternative ideas the squad decided against (but might come back to when iterating on the concept later).
At Saiga, we didn’t use the product pipeline as a to-do list. The board didn’t outline the different actions assigned to certain team members required to move an initiative forward. For this, the squads had their own squad boards in JIRA where tickets for the different activities related to an initiative were tracked. The JIRA squad boards were used during dailies to examine daily progress and blockers. The product pipeline was looked at by the whole squad during their weekly squad meeting to evaluate high-level progress. It was also used on a daily basis by everyone involved in product discovery to document their decisions and findings and to communicate progress to stakeholders. The problem with this setup is that you will probably have some redundant information in Notion and JIRA. A software tool that promises to solve this redundancy issue is Delibr. I’ve never tried it myself but from what I’ve seen and heard it seems like a helpful software that combines the best of both worlds while avoiding redundancies.
If you want to make use of our product pipeline blueprint, feel free to use this Notion template.
Artifact 6: planning and progress-tracking document
Collaborative product development requires each squad to regularly sit down, plan what to do next, and discuss the progress on initiatives they’ve made so far (e.g. in a sprint planning meeting or a (bi-)weekly squad meeting). This could be done by looking at the squad’s product pipeline and documenting progress and targets for the next period right within that board.
Based on my experience, though, running such planning sessions only along a board can easily get messy. You lose track of your overall priorities across different columns of your board and you do not see what goals were set last time at a glance.
Hence, I’m a big fan of using a separate artifact to track progress and short-term targets in addition to the product pipeline, something I call the “planning and progress-tracking document”. The goal is to make priorities and wishful time boxes more explicit. The doc also serves as a snapshot to refer to when the squad needs to make trade-offs or communicate changes along the way.
At Saiga, we ran a Scrumban approach with weekly squad meetings. For those so-called “weeklies”, we implemented a format inspired by what a colleague discovered from his work at GetYourGuide (a Berlin-based scale-up in the travel tech space) and what I had formerly set up at Babbel (a Berlin-based scale-up building a language learning app).
The typical agenda ran along the “planning and progress-tracking document” as follows:
- The progress of the past week is reviewed and evaluated. The milestones that had been defined the week before are evaluated via a traffic light system.
🟢 green = completed
🟡 yellow = started but not finished
🔴 red = did not start
🔵 blue = something we worked on but hadn’t originally planned
Both delivery and discovery progress is assessed (for the delivery part the development velocity is tracked and reviewed too). - The next week is planned by listing objectives for different initiatives and assigning them a priority.
P1 = Most important thing to complete this week. Should always turn green, except in case of unknown unknowns. If not on track by mid-week, drop work on other P’s.
P2 = Important, but not critical. Should never end up red, but yellow is acceptable.
P3 = Supportive or nice-to-have things to get done. Should be green or yellow, but OK if it ends up red (but not 2 weeks in a row).
The priority assignment is particularly important as it underlines where the squad should first focus. - Last but not least, former releases are reviewed. Were success metrics hit? Did we receive any qualitative feedback from users?
If you want to experiment with a similar structure, use this Notion template as a starting point and adjust it to your needs.
Artifact 7: product principles
Last, but certainly not least, IMHO a product artifact stack needs a set of product principles. Product principles are yet another decision-making tool. According to product guru Marty Cagan, “Product principles speak to the nature of the products you want to create.” They guardrail not only WHAT kind of product you build but also HOW you deliver it, the experience you create.
I’ve listed product principles at the bottom of the product artifact stack exactly because of their impact on the HOW. Principles support down to the lowest level of execution rather than only informing the higher-level strategic levels. They help teams evaluate if they are implementing solutions in the right way.
At this year’s MTP conference in Hamburg, Martin Eriksson comprehensively outlined what makes an effective product principle and provided several examples. My main takeaway: Principles are specific about trade-offs. Use “x over y” statements to stress this. I highly recommend watching the entire talk here.
I haven’t developed any product principle artifact template worth sharing. Yet, I love how Slack set up a company-wide rollout campaign for their product principles with emojis, leaflets, stickers, boards, and more. As with most artifacts, the product principle artifact itself is less important than the process of collaboratively creating, promoting, and using it in your team ceremonies and product work.
Note: I like to differentiate between product principles (=principles that define how your product should look, feel, and work) and product development principles (=principles that define how you as a cross-functional team work together to build this product, as described in the first part of this article). Many companies, however, combine these two types of principles to keep it simple.
Want more?
As I mentioned in part one, every company has a unique product, company culture, and team topology. As a result, artifacts cannot simply be copied from one company to another.
However, other company artifacts can be a great source of inspiration. I hope the above examples and templates help you get started or inspire you to further adjust the artifacts you already have in place. For more artifact examples and templates take a look at this valuable list from the Silicon Valley Product Group.
Have you experienced something different? Got some lessons you can share? Comment below and help me improve my product artifact stack and templates 🙏.
