(Re)designing how we work
What I expect of QM Designers.
Two months ago, I stepped into a new role at Quantum Metric: Head of Product Design. In some ways, this is a net-new role, but as I reflect, I realize that as a Staff IC, I was holding myself and my team to these standards. The role, and the moment in our company transformation, made it more official.
I wrote a document on how design should show up in the work and the relationships that it carries.
Below is a public version of that doc.
Our working tenets
- We organize design around the jobs customers bring to the product, and we judge each area by what a customer can now do without us.
- We work on a few things at a time, finish them, and let the design system carry the rest.
- Work can always be better, so we make time to learn from how customers use what we ship, and we iterate.
- AI doesn’t replace the role of the designer, it supercharges it. We can outsource, enhance, and automate parts of our work, but the human owns the outcome, experience, and deliverables.
Domains
Our company is maniacally focused on reinventing digital customer analytics in the age of AI. This means that we are doubling down on Felix AI as the future of our product offering.
Based on the work ahead of us and the company vision, I worked with product and engineering leadership to define domains.
It may be easy to equate these domains to workstreams. But instead of predefined roadmaps full of features, they’re outcome-driven.
Each domain anchors itself with a sentence about the customer job: what they can do in our product autonomously.
Each domain has a leading metric to help us track if the outcomes are delivering. And they also map clearly to company OKRs, sometimes one, sometimes multiple.
Drivers
Every domain has drivers: all-star ICs who are responsible for ownership and outcomes in their given domain.
Design drivers partner with copilots in product and engineering. While those copilots have their own set of expectations and norms, we’re all aligned to the experience and outcomes we are building toward.
The R&D leadership, myself included, enable the drivers and then get out of their way. Of course, I’m always there to unblock, crit, ideate, and jam, but my hope is that these domains can be autonomous, letting the experts do their best work.
How design drivers operate
Design drivers are always looking to find the next thing. They look for customer friction, pain and identify emerging product opportunities. This means that they are constantly talking to customers, our field partners, and support team.
Design drivers work with a product driver to propose what’s next on their roadmap, leading with data-driven evidence and strong proposals.
Drivers start from the customer’s job, not a product spec. They bring that POV before a requirement doc or PRD exists.
Drivers make decisions without waiting for permission, and bring those decisions to design critiques and jams.
Drivers pull engineers in at the right moments. Sometimes it’s in the early stages, especially when technical solutions shape the direction. Other times, it’s after the work has been proven out to leadership and validated with customers.
Drivers should keep no more than three things in progress at a given time, only starting on the next when one of the three is finished. It’s my job to protect that focus and take drive-by requests off their plate.
Drivers talk to customers regularly and fix what they see in the product themselves. This means authoring and pushing out merge requests. My job is to inspect the work, not the person. My lens is always: “Can a customer use it without someone walking them through it? Do they trust it?”
Drivers own the full-stack design process. They also own the mobile (responsive web and mobile app) execution of their domain work.
Drivers design how the AI finds, offers, and acts on its work. This becomes a focus on not just screens. Trust becomes more important than it ever has in our work.
Trust
Our product answers questions with AI, so trust is one of the biggest focuses in our work as designers and owners of the experience. We must show how AI got to an answer or an insight. Data analysis needs to be deterministic. When AI can’t answer something or is unsure, it needs to call that out. If it takes a wrong turn, it needs to recover and show the recovery.
In every crit or jam, we constantly ask ourselves whether a customer would act on an insight or CTA without having to “check the work” themselves somewhere else (on or off our platform).
Final thoughts
This working model is familiar by design. It expands on the way we already worked and brings a focus and rigor for the age of product development and design that is AI assisted.
I know it will change, as much of our processes do over time. But for now, this is how I’m leading my team.
Proof of human: Human Written, according to Pangram 4.1.