User needs are more valuable than assumptions.
I’m Chris Hart. Accorderly is my consulting practice for small product teams. My role covers product, UX research, and development. I’m a freelance Chief Product Technology Officer (CPTO).
I've consulted for product teams at
What I work on
Small-team software delivery, structured around a continuous process of Discovery, Design, DevOps that run in parallel. The model is a synthesis of practices I honed over 20 years of software product leadership.
- Discovery is the weekly habit of customer interviews feeding an Opportunity Solution Tree, in the sense Teresa Torres describes in Continuous Discovery Habits.
- Design is shaping the work before any code is written, in the sense Ryan Singer uses Shape Up at Basecamp, layered on the UK Design Council’s Double Diamond, the model that names the shape.
- DevOps is the build / ship / observe loop, in the sense of The DevOps Handbook. It runs in parallel, not as a final phase, because of the shift-left approach (Larry Smith, 2001): do the things at the end of the timeline earlier.
If you want to know more, or think these practices might help you, email me or book a call.
How I build knowledge-driven applications
Useful knowledge-driven apps (AI or not) rest on three parts that work as one:
- Models parse external facts into a logical data format. Machine learning is good at pattern matching: it recognizes things it has seen before. Smaller and cheaper models are usually the best fit for embedding in applications. Sometimes there is no ML needed and a plain old search index works well.
- Rules check the processed data for correctness and implications. Rules and logic are good at explanations: they show why a decision follows from the facts. And they’re totally deterministic, which means control over potential liability.
- People drive the living goals and the desired outputs. A person reviews the result and can see how it was reached. But beforehand they also configure domain-specific rules that cannot be left to mere probability. This is a step above so-called “human in the loop”, and completely avoids the “reverse centaur” trap coined by Cory Doctorow.
It runs on proven data engineering pipelines that have powered enterprises for over a decade before the latest AI models were even released.
I have commercialized this AI framework with many companies including the ones shown above. These systems show their work, which is what makes AI safe to use where “the model said so” is not good enough.
AI ethics policy
- No generative AI for creative work: nothing that writes copy, and nothing that makes images or artwork.
- No chatbots or thin model wrappers, but embedded command palettes and composer features are fully supported.
- Voice AI is input only. It can transcribe what a person says, but verified copyright permission from the original speaker is needed to ship synthetic voices.
- Generative output is never treated as fact. Language models can't verify their own answers, so anything presented as fact gets checked against an original source.
- Code and data generation is supported inside environments where every output can be checked deterministically. Courts have already held a companies liable for what chatbots tell customers.
- Open source or open weight models only. Because most training data was gathered without permission, models that anyone can run give some protection back to the community.
- No products marketed towards replacing jobs or avoiding doom.
Creative and strategic work stays with real people.
What engagements look like
Fixed scope
When the problem is well-defined and the answer is mostly known.
Retainer
When you need a steady delivery partner for a quarter or more.
Hourly
When the work is open-ended and you want someone senior on call.
Embedded
When you need an extra senior on the team for a stretch, and the work is the kind I do.
The first conversation
Short, free, and ends with one of three outcomes: a clear next step, a polite no, or a referral to someone better suited. Book a call →
What you get
Slices of working software shipped to real users where the engagement allows. A slice is feature-complete, end-to-end set of functionality that can be tested at all levels of the implementation, even if it might not be ready for massive scale.
Discovery hands off a hypothesis. Design shapes the scope of the slice. DevOps ships the slice, and finally the learning from the deployment environment flows back into Discovery again. Rinse and repeat as needed.
User cohorts are usually small and limited (just enough for statistical significance), either through feature flagging (a rule decides who sees the code in production) or canary releases (a small slice of traffic widens only if metrics hold).
The triple diamond
Each diamond runs on its own clock, but they overlap and can be layered depending on team capacity. Running them together keeps decisions close to the work product, and the work product close to the user.
If this delivery model sounds like a fit for your situation, let’s talk.
Book a call →Reach me
- Email — hello@accorderly.com
- Book a call — cal.eu/accorderly ↗
- LinkedIn — Accorderly ↗ or my profile ↗