Make recurring client work easier to deliver
Help shape tools that reduce repetitive work while keeping expert judgment in the decisions that need it. I am interviewing independent consultants and fractional leaders about the workflows, exceptions, and review needs that determine whether software is useful in client delivery.
Research conversation. No pitch or sales follow-up.
Research questions
Questions guiding the study
The study focuses on the gap between a useful AI demo and software a consultant can trust inside real client work.
Which client workflows are repeatable enough to become software?
I am looking for work that happens often, has a recognizable starting point, and produces an outcome a client already values.
Where does expert judgment belong?
The goal is to separate decisions that require experience from work a system can handle safely and consistently.
Why have earlier automation attempts failed?
Messy inputs, exceptions, weak review controls, poor fit with client work, and loss of trust are all part of the research.
What would make the result usable with a paying client?
A useful prototype must become dependable work product, with clear ownership, review, and accountability.
Client-ready criteria
Criteria for dependable software
These are the working criteria I am testing in the interviews. The research may change them.
- It follows the consultant's method instead of flattening it into a generic prompt.
- It handles incomplete, inconsistent, and client-specific inputs without hiding uncertainty.
- It shows its work well enough for an expert to review the important decisions.
- It keeps the consultant in control of approval, revision, and delivery.
- It produces work the consultant would be willing to put in front of a paying client.
The six-step method
From consulting method to software
The research will determine whether this method should become an educational program for experienced practitioners learning the software toolchain.
- 01
Choose a valuable workflow
Start with a recurring client outcome that matters enough to improve.
- 02
Define what done means
Make the required result, acceptance checks, and failure conditions explicit.
- 03
Set the boundaries
Define which data the system may use and which decisions remain with the expert.
- 04
Build the smallest complete path
Run one representative input through to a useful, reviewable client outcome.
- 05
Test failures and repair them
Use difficult cases to expose weak assumptions, unsafe behavior, and missing controls.
- 06
Demonstrate and transfer ownership
Show the evidence, support the result, and leave the practitioner able to operate it.
Worked example
ClientScope
Illustrative research prototype
ClientScope is not a product being offered to participants. The interview is not a product demonstration, sales qualification, or invitation to buy it.
The prototype makes the research method concrete by turning a synthetic discovery-call transcript into a reviewed scope, work plan, and explicit record of what is still unknown.
Input
A synthetic discovery-call transcript, delivery constraints, and the consultant's scoping rules.
Analysis
The system finds goals, assumptions, unknowns, dependencies, and conflicts. It marks uncertainty instead of filling gaps silently.
Expert review
The consultant resolves open questions, adjusts the work plan, and approves every promise made to the client.
Output
A proposed scope, deliverables, exclusions, unanswered questions, acceptance checks, and work plan. Every material statement traces to the source conversation; unsupported assumptions stay visible.
The software handles extraction, comparison, and assembly. The consultant still owns the advice, tradeoffs, commitments, and final client conversation.
Participant fit
Who I am interviewing
I would like to speak with independent consultants, boutique firm leaders, and fractional executives who deliver recurring advisory or knowledge work.
- You have a workflow you perform across multiple clients.
- The work includes judgment that templates or basic automation miss.
- You have tried AI or automation, or have a clear reason you have not.
- You care about quality, client trust, and where human review belongs.
The interview
The 20-minute interview
- 2 min
Context
Your practice, clients, and the work you are known for.
- 8 min
One workflow
A recurring job, from the first input through client delivery.
- 6 min
Friction and trust
Exceptions, failed automation, review needs, and client risk.
- 4 min
Close
What a useful tool would need to do, and what it should never do.
Afterward, I will send you a concise, one-page opportunity brief based on the workflow we discussed.
Research boundaries
Participation and privacy
No sales call
I will not use the interview to sell consulting, software, or another service.
No client secrets
You can describe the workflow without sharing client names, files, or confidential details.
Aggregate reporting
MPIV will publish patterns across interviews and send every participant the summary.
Permission stays explicit
I will not identify you or quote you without asking and receiving explicit permission.
About the researcher
About Michael Isaac
I am Michael Isaac, founder of MPIsaac Ventures. My work has crossed enterprise consulting, software delivery, product leadership, company building, and AI. I am running this research because experienced practitioners understand the hard part of turning a method into reliable client work: the exceptions, judgment, and accountability that a demo leaves out.
32 years
Consulting, software, product, and company-building experience behind the study.
Participate
Take part in the research
I will examine how it works, where judgment enters, and what reliable software would need to preserve. I will send you the aggregated findings when the research is complete.
Book a 20-minute interview