PRODUCT STRATEGY & VALIDATION
Product and technology strategy, rapid AI-assisted prototyping and independent technical assessment, aimed at reducing uncertainty before a larger investment in development.
FOCUS AREAS
Working out what the product actually needs to do, for whom, and whether it is worth building at all.
Turning a concept into a working prototype quickly enough to test it before it becomes a bigger engineering commitment.
An independent, vendor-neutral view on system design, an existing architecture, or someone else’s proposal.
Generative AI and agents used where they solve a real problem, not because a roadmap says AI has to be somewhere.
STARTING POINTS
APPROACH
Starts with the problem, the business context, the users and the constraints, not with a chosen technology.
The riskiest assumption gets identified early. That is usually what decides whether a project succeeds or fails.
Depending on the question, this means a prototype, a system analysis, or an architecture review: whatever actually answers it.
The assumption gets tested against something real: users, data, or a working system, not opinions in a meeting.
The result is a decision: build, adjust the scope, wait, or stop. Each of those can be the right call.
SELECTED EXPERIENCE
Anonymised on purpose: no client names, no confidential figures. Descriptions cover the kind of work and the kind of value delivered.
A founder had a clear idea and a good read on the market, but only a slide deck to show for it. Conversations with potential investors and partners kept stalling on the same question: what does it actually do.
A focused, AI-assisted prototype of the single most important workflow, built in days rather than weeks, using realistic sample data instead of a real backend.
The idea became something people could click through and react to. It also cut the original scope down significantly: not every feature in the first plan survived contact with a working version.
Two people inside the same organisation disagreed about which technical approach to take for a new product idea. Both had reasonable arguments, and neither side was going to concede on opinion alone.
Building small working versions of both approaches turned out to be faster than continuing the discussion. One version made the trade-offs obvious within days. The decision that followed was more popular with one side than the other, but it was based on something concrete.
An organisation had scoped a fairly large product around one flagship feature, based mostly on internal conviction rather than user evidence.
Whether that flagship feature was actually the reason people would use the product, or just the reason it was easy to pitch internally.
In practice, users largely ignored the flagship feature and kept returning to a smaller, secondary workflow instead.
The scope was reduced substantially around that smaller workflow. Some of that was uncomfortable for people who had already committed to the original plan, but the revised version was something people actually used.
An organisation was about to commit to a multi-month development contract, based on a vendor proposal that looked solid and was priced accordingly.
An independent technical review questioned the proposed architecture, decomposed the estimate, and ranked the risks instead of taking the proposal at face value.
A few line items turned out to be poorly justified once questioned directly. The contract was restructured into phases with clearer checkpoints before the next payment.
ABOUT
Most software products don’t fail because of the code. They fail because business and engineering never agreed on what the product actually needed to do.
I’ve worked on both sides of that gap: writing software, leading engineering teams, and carrying commercial responsibility for technology work in international organisations. minicki consulting grew out of that combination.
Most of the work happens early, before a serious budget gets committed to a direction that might turn out to be wrong: framing the problem, testing the riskiest assumption, and building a prototype where that’s the fastest way to get an answer.
AI-assisted development, including coding agents, is part of that process now. Mostly it changes the timeline, a working prototype in days rather than months, not the kind of decision being made.
LAB
These are explorations and prototypes, built to learn, not finished products.
PRINCIPLES
CONTACT
This usually starts with a short, honest description of the problem: a product idea, a build decision, a vendor proposal, or an AI use case that still feels vague.