Skip to content

process / akshay gite

From a loose idea to a product people can test and investors can see.

I work with founders and small teams who have ambition and not enough structure yet. This is the full method: how I find the problem worth solving, cut it down to an MVP, and prototype it well enough to test with users and pitch to investors.

Start a conversationSee the work ↓

what idesignagainst

A good MVP sits where three things overlap.

What people struggle with.

User evidence first. Interviews, support logs, analytics, reviews, and the steps where people give up. I look for pain that is frequent, costly, and already being worked around.

What is now possible.

AI models have opened product territory that was too expensive or too slow to build two years ago. Much of it is still unexplored. I check which new capabilities solve a real pain, and which ones are just a demo.

What the market will back.

A problem is only worth building for if someone will pay and the timing is right. I look at who is already solving it, how the current funding climate treats the category, and what a small team can credibly ship.

Most products fail on one of these. The method below checks all three at every stage.

themethod

Open the problem up, narrow it down. Then do the same for the solution.

Each stage ends with something concrete you can use, share, or decide on. You can stop after any stage and keep what we made.

How the work runs, from the founder's side One dot opens into a lens of many dots, the evidence, and narrows into a framed problem. Three ribbons open from it and close again into three feature slabs, then a phone, the prototype. Rows of test dots lead to a chip: evidence. An arc loops from 05 back to 03. evidence 03 to 05 repeat problem solution 01 02 03 04 05
How the work runs, from the founder's side Top to bottom: one dot opens into many and narrows into a framed problem; three ribbons open and close into three feature slabs and a phone; rows of test dots lead to evidence. An arc loops from 05 back to 03. evidence problem solution 03 to 05 repeat 01 02 03 04 05
  1. 01

    Map the whole journey

    I start wide. Every step from first hearing about the product to coming back a second time, including the parts outside the screen. Founder assumptions go on the map too, marked as assumptions.

    Stage 01: the whole journey, mapped Eleven dots in a row are the steps of the user journey, from first hearing about the product to coming back a second time; two are hollow because they happen off screen. Dot size is how much a step hurts: how often it happens and what it costs the user. One dot, the top-ranked pain point, is huge. The founder's assumption is a small dashed circle. the real pain isn't the assumed one assumption top-ranked pain point off screen
    Stage 01: the whole journey, mapped Eleven dots top to bottom are the steps of the user journey; two are hollow because they happen off screen. Dot size is how much a step hurts. The top-ranked pain point is huge; the founder's assumption is a small dashed circle. the real pain isn't the assumed one assumption top-ranked pain point off screen
    where ai helps
    Synthesising interview transcripts, reviews, and support tickets into themes, so more of my time goes to talking with people.
    you get
    A journey map with pain points ranked by how often they happen and how much they cost the user.
  2. 02

    Name the pain worth solving

    Then I narrow. We pick the one to three pain points that matter most and write down what we are deliberately not solving yet. This is where most scope creep gets stopped.

    Stage 02: naming the pain worth solving The journey row from stage 01, now grey. Two pain points, the top-ranked one and a smaller one, are lifted out of it into a framed box: the problem statement, the pain worth solving, with its evidence. The founder's assumption is struck through; the rest of the row is marked out of scope. decided together in a workshop assumption the pain worth solving, with evidence problem the rest: out of scope
    Stage 02: naming the pain worth solving The journey column from stage 01, now grey. Two pain points are lifted out sideways into a framed box: the problem statement, the pain worth solving, with its evidence. The founder's assumption is struck through; the rest is marked out of scope. decided together in a workshop assumption the pain worth solving, with evidence problem the rest: out of scope
    where ai helps
    Stress-testing the problem statement against the evidence, and surfacing edge cases we would otherwise meet in development.
    you get
    A problem statement, the evidence behind it, and a written list of what is out of scope.
  3. 03

    Explore more than one answer

    I open up again, this time on solutions. I develop a few directions, including ones built on new AI capabilities, and check each one against user value, build effort, and market case. Engineers join here, not after.

    Stage 03: more than one answer The framed problem from stage 02 sends out three ribbons to three phone sketches, each checked against user value, build effort and market case: a, a crowded market, full of look-alikes; b, the best user value, the thickest ribbon; c, high build effort, which uses AI. An arrow moves c's AI step into b, the recommendation. recommend b, with c's AI step built in crowded market best user value high build effort a b c uses ai
    Stage 03: more than one answer The framed problem sends three ribbons to three phone sketches: a, a crowded market, full of look-alikes; b, the best user value, the thickest ribbon; c, high build effort, which uses AI. An arrow moves c's AI step into b, the recommendation. recommend b, with c's AI step built in crowded market best user value high build effort a b c uses ai
    where ai helps
    Fast rough variations and quick technical spikes to see what a model can actually do with real inputs.
    you get
    Two or three directions compared side by side, with a recommendation and the reasoning.
  4. 04

    Cut to the MVP and prototype it

    I narrow to the smallest feature set that proves the core promise. Then I build a clickable prototype with realistic content, empty states, and errors, detailed enough that users react to it as a product and investors can see it working.

    Stage 04: cutting to the MVP and prototyping it Six upright slabs are features, tallest first. An mvp line cuts after the third: the smallest feature set that proves the core promise stays solid, and three grey outlines are marked later. A bracket over the three kept slabs carries them, past the later ones, into a phone, the prototype, where they become three bars. one core promise, smallest feature set later prototype mvp line
    Stage 04: cutting to the MVP and prototyping it Six upright slabs are features. An mvp line cuts after the third: the three that prove the core promise stay solid, three grey outlines are marked later. An arrow carries the kept three down into a phone, the prototype. one core promise, smallest feature set later prototype mvp line
    where ai helps
    Front-end prototypes and variant flows built in days, so we test the real interaction instead of static screens.
    you get
    A prioritised MVP feature list with the reason for each feature, and a working prototype ready for testing and pitching.
  5. 05

    Test, learn, redesign

    I put the prototype in front of real users, sort the feedback into what changes the product and what is noise, and redesign. Then we run the loop again. Each round is documented, so you can show investors how the product earned its shape.

    Stage 05: test, learn, redesign Three rows of five circles are three test rounds with five users each. Filled circles finished without help: 1 of 5, then 3 of 5, then 4 of 5. Curved arrows between the rows are the redesign before the next round, each labelled with what changed in the change log: fixed the empty state, then a clearer error message. 4 of 5 finished alone: ready to pitch changed: fixed the empty state changed: clearer error message 1 of 5 3 of 5 4 of 5
    Stage 05: test, learn, redesign Three rows of five circles are three test rounds with five users each. Filled circles finished without help: 1 of 5, then 3 of 5, then 4 of 5. Curved arrows between rows are the redesign, labelled with what changed: fixed the empty state, then a clearer error message. 4 of 5 finished alone: ready to pitch changed: fixed the empty state changed: clearer error message 1 of 5 3 of 5 4 of 5
    where ai helps
    Clustering feedback across sessions and tracking which issues repeat between rounds.
    you get
    A change log of what we tested, what we learned, and what changed as a result.

Stages 03 to 05 repeat until the prototype holds up with users.

for foundersraising

A prototype that answers the questions investors ask.

Investors are not buying screens. They want to see a real pain, evidence that people have it, a reason this is possible now, and a team that knows what not to build. The method produces each of these as a by-product, so the pitch prototype is the design work, not a separate deck exercise.

What you can show investors, and where it comes from Investors' five questions, each answered by something made during the work: is the problem real by the ranked pains, why now by an AI check that fills a form from a photo, can this team ship it by the cut feature list, do users want it by three test rounds. Lines from each run into one phone, the prototype, which answers can I see it. A dashed slide deck beside it is struck out. prototype Is the problem real? Why now? Can this team ship it? Do users want it? Can I see it? deck proof made along the way what investors ask made during the work 01 02 03 04 05
What you can show investors, and where it comes from Investors' five questions, stacked, each above the thing made during the work that answers it: ranked pains, an AI check that fills a form from a photo, the cut feature list and test rounds. A line gathers them into one phone, the prototype, which answers can I see it. A dashed deck is struck out. proof made along the way prototype deck Is the problem real? Why now? Can this team ship it? Do users want it? Can I see it? 01 02 03 04 05
  1. 01

    Is the problem real?

    Ranked pain points and the evidence behind them.

    stages 01 and 02
  2. 02

    Why now?

    The technology and market check in stage 03.

    stage 03
  3. 03

    Can this team ship it?

    A tight MVP scope with a written out-of-scope list.

    stage 04
  4. 04

    Do users want it?

    Test rounds and the change log.

    stage 05
  5. 05

    Can I see it?

    A working prototype, not a slideshow.

this sideof thetable

I have been the founder, not only the designer.

I am the founding designer at OHR.FM, a social music discovery platform, where I work directly with the CEO and CTO on product direction. Before that I founded Altrue, an AI-guided microdonation product, and took it to a working MVP on my own.

I paused Altrue when it became clear that payments, fund distribution, and trust in a charity-adjacent space needed more than one person could responsibly deliver. That decision taught me as much as building it did. I now help founders see those walls early, before they spend a year running into them.

Read the Altrue case study →

Before freelancing: 10+ years at Airalo, IKEA, H&M, and Husqvarna, through frog and in-house.

ai inthemethod

AI shortens the distance to evidence. The decisions stay mine.

Prototype earlier.

Realistic, clickable flows before a team commits to build.

Stress-test product logic.

Edge cases, empty states, onboarding paths, and variant flows, found before development instead of during it.

Edit with judgement.

AI produces more options. My job is to narrow them, protect the user, and decide what not to ship.

engagements

Start with one stage or run the whole method.

Which stages each engagement covers
Engagement0102030405
Problem sprintcoveredcoverednot coverednot coverednot covered
MVP and pitch prototypecoveredcoveredcoveredcoveredcovered
Redesign loopnot coverednot coveredcoveredcoveredcovered
Workshopany one stage

halfformed?

Have something half-formed? That is the right time.

Send rough notes, a deck, or a link. Tell me what you are trying to validate, build, or pitch. I reply within 2 working days.

  1. 01 start a conversation
  2. 02 email me directly
  3. 03 see the work
  4. 04 read about me

Your message is only used to reply to you. See Privacy.