Ionut Maxim

The case-study page lies in the most flattering way.

Every consultancy site has a Work page. Almost none have a What-I-Got-Wrong page. The case studies are honest about what shipped; they are quiet about the engagements that taught me the most, which are usually the ones that did not go to plan. Three short stories, sanitised. The setup, what actually happened, and what I changed about how I work because of it. If you are thinking of working with me, this page is more useful than the Work one.

  1. 01

    The redesign that fixed nothing

    The setup. A B2B SaaS engagement, late-stage. The brief came in as a "redesign of a tool that feels dated". Eight-week scope, mid-five-figure budget. The team was earnest and the brief was honest.

    What actually happened. Six weeks in I had assembled enough conviction that the actual question was not visual. The team was disagreeing — quietly, in the work, not in the meetings — on what the tool was actually for. The redesign was the disguise. I had spent five weeks polishing the wrong thing because the symptom looked exactly like a redesign problem.

    What I learned. The one-sentence-test (write what the product is for, by hand, three people independently) costs about an hour and would have surfaced the disagreement in week one. I now run it before anything visual on any engagement that started life as a "redesign".

  2. 02

    The listening week that learned the wrong thing

    The setup. An early-stage consumer product. Listening week as planned — three days of internal conversations, two days of user calls, a written diagnosis at the end.

    What actually happened. The user calls were with the most articulate users I could find on short notice. They were also the three power users. The diagnosis I wrote was crisp, confidently delivered, and load-bearing for the next three months of work — and quietly wrong on the question that mattered most. The mediocre and quiet users would have told a different story.

    What I learned. Build the user-selection rubric first, with the client, and bias toward the quieter end. Articulate is not representative. Three thoughtful calls with mid-engagement users beat ten with power users for diagnostic purposes — and I write that into briefs now.

  3. 03

    The engagement that should have ended at week two

    The setup. A twelve-week diagnostic-plus-design contract. Mid-stage product, real revenue, capable team.

    What actually happened. The answer was effectively in by the end of week two. The team needed to make a decision and stop, not run a redesign. I extended scope for another nine weeks because I had convinced myself the team needed me to "see it through". The team needed me to leave the room and let them act on the diagnosis. The work I shipped was fine and unnecessary.

    What I learned. End engagements when the answer is in, not when the calendar says. I now structure listening-week contracts with an explicit "we stop here if the answer is enough" clause, priced as a separate fee. The client almost always picks that option, and the work that follows — if it follows — is sharper for it.

If something feels off, start there.

Tell me what's going on and what a good outcome would look like. A short email is enough — I read every one and reply within two working days.

Start a conversation