7 artifacts for effective product development (incl. templates) — part 1
This is the first of a two-part article. You can read the second part here.
Product development is complex.
It’s about building a great product with a cross-functional product development team. A team that usually consists of engineering, product design, product management, and sometimes user research, data analytics, copywriting etc. You have to do the product building AND create the system needed to make the building happen. This system requires a range of principles, tools, roles, processes, and ceremonies …
Hardware vs software
In the hardware world, this ‘system building’ is usually a full-time job for a production/factory planner/manager. It receives a lot of attention (see Elon Musk who frequently talks about “building the machine that builds the machine”).
In the software world, it usually isn’t a dedicated job (unless your organization is big and state-of-the-art enough to have a product ops function). Typically, the system needs to be created by the very same people responsible for building the product, aka the cross-functional product development teams (the ‘squads’) together with their respective leadership teams. Agile coaches may support, but they are usually only focused on a dedicated part of the system (i.e. how to best set up product delivery).
So there you are, building the plane while flying it…
Building your product development system with artifacts
This two-part article aims to make this ‘system building’ a little easier. In it I’ll share the seven key product development artifacts that have previously helped me to create effective systems (I call them ‘the product artifact stack’):
- Product development process & principles
- Role descriptions
- Product vision and strategy
- Outcome roadmap
- Product pipeline
- Planning & progress chart
- Product principles
Part one of this article (which you’re reading) looks at what a product artifact is, before outlining the first two artifacts of the stack which define how product development is done collaboratively.
Part two of this article outlines the remaining five artifacts which define what a squad / product organization is focussing on at different levels of execution.
I’ll provide templates for five of these artifacts which you can copy, adjust, and use as you see fit.
I see these seven key artifacts together with a defined rhythm (aka a set of ceremonies) as the cornerstones of a well-oiled product development machine. Most other artifacts required for successful day-to-day product development can be built on top of this base.
But, first things first…
What is a product development artifact?
I first learned about the term ‘product development artifact’ while working as a Head of Product for Babbel (a Berlin-based scale-up building a language learning app).
In the process of redefining “how we do product development,” the CPO at Babbel asked the team what our key product development artifacts were. “What’s an artifact?” I thought (before quickly Googling the term!).
I found the following definition: “an artifact is an object made by a human being that reveals something about the culture of its human creators.” Translation? I define the term ‘product development artifact’ as follows:
A product development artifact is an object that manifests and/or enables the product development system of a company or squad. This can be a tool, or a piece of documentation of a process, principle, or role.
Note: in my definition, I’ve consciously exchanged the term ‘culture’ with ‘system’. A lot of people associate the term ‘culture’ with something fluffy (i.e. team events rather than the more general ‘way how we work together’). To avoid that association, I prefer to refer to the processes, tools, principles, and roles that make up the ‘product development culture’ as those that make up the ‘product development system’.
How can an artifact help establish an effective product development system?
Discussing and defining Babbel’s key artifacts seemed like a smart thing to do as a product leadership team.
Developing artifacts brings clarity and alignment to the way a product is built. You either create a new part of the system to streamline a repetitive activity (e.g. release note principles) or you make a best-practice behavior that’s existed, but not been consistently used across squads yet, explicit (e.g. with a template for running effective retrospectives).
Discovering product development artifacts was an eye-opening experience. Now, every time I join or build up a new product development organization, or coach product managers, I always ask myself or them: what are your key artifacts?
IMHO: the moment a cross-functional group gets together to develop a product, they should define some key artifacts as a base. The full product artifact stack should then, at the latest, be defined once there are multiple squads and several stakeholders that need to align and work together towards the same goal.
I’ve experienced many start-ups (and even scale-ups!) shrinking back from defining artifacts by labeling it as “too corporate”. This backfires. If you build a product, by default you have a system that makes this building happen. If you don’t define it proactively, and just let it happen, it’s likely to be inefficient and unclear for the existing team and any new joiners.
Artifacts proactively create a productive product development system. Helping to make the implicit, explicit.
The 2 artifacts that manifest how product development is done collaboratively in a squad or company
At the core of every product development system, is the overarching philosophy of how to do things collaboratively. With collaboration I refer to a multi-skilled team working together synchronously, or in a coordinated manner, to complete a task in support of a shared objective.
I go into more detail on this in my article on collaborative product development.
Based on my experience, there are two critical elements when it comes to setting up smooth collaboration: a defined product development process and principles as well as clear role descriptions for everyone in the team.
Artifact 1: product development principles and process
Why is it important to define a product development process and principles?
Because different disciplines usually have different perspectives and frameworks when it comes to product development. Engineers are familiar with SCRUM, designers think in the double-diamond framework, and PMs are fans of how Jeff Patton scribbled down the hypotheses-driven product development process.
These different frameworks usually focus on different aspects of the process and need to be brought together to frame an end-to-end development circle. And these frameworks often use different terminology to refer to the same thing but, for efficient collaboration, people need to speak the same language and understand how their activities impact the work of others.
A well-defined process and principles cover the end-to-end development cycle, specify terminology, and explain dependencies.
Below are the principles and processes we defined at Saiga, a start-up that developed an AI-driven personal digital assistant where I led product management and product design as co-founder and CPO.
Here’s how to read our process diagram:
- There are four main phases: ‘Analysis & Research’, ‘Concept & Design’, ‘Delivery’, ‘QA & Rollout’.
- While everyone on a squad should be involved in every phase, we’ve defined which function is in the lead. This provides clarity within the squad and for stakeholders. Leadership is often dependent on the type of initiative a squad is working on. In the ‘Concept & Design’ phase, if it’s an interface-heavy initiative then product design guides everyone through. If it’s about defining a refactoring concept for the backend to make the application faster then engineering is in the lead.
- Rectangles and triangles describe the different steps within a phase. The width indicates if this is usually a step that takes a little longer (i.e. exploring problems) or if it’s something that can be done within a decision meeting (i.e. prioritizing problems).
- Ovals describe the deliverables / thresholds within, or between, phases that are required to take the next step. Having clearly defined deliverables serves as a reminder for the people in the lead to not just hurry through or even skip over a certain step. They describe what a successful outcome of the former step(s) looks like, i.e. that a ‘ready-user story ticket’ should include some implementation notes (which means that there must have been a structured implementation discussion in the former step ‘plan implementation’).
- The ‘risk marks’ at the top describe which kind of initiative enters or re-enters the process at which phase. If for example an initiative is low risk (aka a clear problem with a solution that has already been proven by many other companies, i.e. a password reset functionality) you should not waste time on research and analysis but start with defining the best practice solution.
- Super important: while the process looks linear at first sight, the backward arrows indicate how you move back and forth between different stages. And how measuring success usually leads you back to the beginning to work on the next iteration.
- The trash bins indicate that in almost every phase you will need to throw an initiative away at some point. The only phase where we wouldn’t call this a sign of bravery, and part of the process, is during ‘testing and rollout’. If this is where you figure out something doesn’t work then you’ve probably done something wrong.
If the way we have sketched out the Saiga process seems like a helpful visualization for you, feel free to use and adjust my Figma template to your needs.
Artifact 2: role descriptions
How do different disciplines best contribute and act upon the above process? By having clear role descriptions for everyone on a product development squad.
Product development is done quite differently from company to company. What a product manager does in one company is done by an engineer in another. And what is owned by a product designer in one company might be part of the product management role in another.
Having clear role responsibilities outlined makes the processes and principles defined above quicker to implement. If less thinking flows into ‘who should be doing this or that’, then more energy is available to make the right product decisions and get work done.
But don’t worry. Having such role descriptions doesn’t mean those roles are 100% mutually exclusive and set in stone. In a collaborative environment, roles overlap by default and need to be flexible.
To describe the responsibilities of a certain role, I combine a description of what success looks like for a role if the activities are done par excellence with an activity wheel.
Petra Wille developed the wheel framework for the product management role (the PMwheel) and I find the structure super helpful for both product managers and for any role in a squad. Why?
- It serves as a compass for people in the squad.
- It helps stakeholders understand who does what and who owns what.
- It can be used as a coaching and personal development tool to assess how well someone is performing in their role.
For more details on this, read my interview with Petra in which we discuss the PMwheel and how I used it while working as a Head of Product for Babbel.
Below is an example of the product design role description I used at Babbel and adjusted for Saiga. To create your own role descriptions, feel free to use my Figma template (which outlines an exemplary product design and product management role).
That’s all (for now)
In part two of this article, I outline the next five artifacts but, before then, an important note…
Don’t just copy and paste!
As every company has a unique product, company culture, and team topology, artifacts cannot simply be copied from one company to another. Artifacts are only as good as the squad’s ability (or the entire product development organization’s) to collaboratively define, refine, and fill them with content.
An example of this is the SCRUM framework. The only way I’ve seen it work is when companies smartly adjust the original framework to their needs. The process of discussing, defining, and refining such an artifact is as important as the artifact itself.
A good place to start is by looking at the artifacts of other companies, which is why I’ve shared two product development artifact templates above. I hope the descriptions and templates help you sharpen and strengthen the product development system of your squad or company. Use them as a starting point, and consider the process of discussing and adjusting them as just as important as your final artifact.
Comment below if you have any questions or thoughts. I’d love to hear about other people’s experiences.
