--- title: "Product Design Process for Startups | Utkarsh Panwar" description: "A product design process for startups that runs as a loop: find the number, find the why, sketch the flow, test cheaply, ship every state, measure again." url: https://www.utkarshdesign.com/guides/product-design-process author: Utkarsh Dhairya Panwar updated: 2026-10-08 --- # The product design process for startups Guide · 5 min read · By [Utkarsh Dhairya Panwar](https://www.utkarshdesign.com/about) · Updated 8 Oct 2026 **A startup product design process works best as a short loop: find the problem in a number, learn why, sketch the flow before screens, test the cheapest fix, ship it with every state, then measure that number again. One turn can take days, and I go round many times.** ## The loop I use 1. **Find the number**: Start from a metric that is moving the wrong way, or not moving: activation, a step in the funnel, support volume, demo length. If nobody can name the number, that's the first job. 2. **Find the why**: Walk the flow as each type of user, read support tickets, watch a few sessions, and talk to two or three people who dropped. You're after one sentence that explains the cause. 3. **Sketch the flow before the screens**: Boxes and arrows at low fidelity, agreed with engineering. Flows are cheap to argue about; screens aren't. 4. **Test the cheapest version**: A prototype in front of five users, an A/B test, or a manual version run by the team for a week. Pick whatever answers the question fastest. 5. **Ship it with every state**: Empty, loading, error, no-permission, success. Then review the coded build before release, while fixes are still cheap. 6. **Measure the same number**: Use the metric you started with, never one picked afterwards. If it moved, find the next problem. If it didn't, the why was wrong, so go back a step. ## One turn of the loop, at CodeAnt The number was drop-off at the step where users connect a repository. The screen was fine. The cause sat in the org chart: installing the GitHub app needs admin rights, and the person who signed up usually wasn't the admin. ![Four-card wireframe flow: no access and no path, email the admin or share a link, the admin sees it in email or Slack, repo connected](https://www.utkarshdesign.com/images/Mul1lsJtfn9tRqKrg4pNquZsQ.webp) _The flow sketch step: the hand-off as boxes and arrows, before any UI._ ![CodeAnt Request Admin Approval modal with an invite link and Copy button, an org admin email field with Send, and a Book a Call link](https://www.utkarshdesign.com/images/codeant-request-admin-approval.webp) _What shipped after testing: two ways to pull the admin in._ The team tested the fix, shipped it with its states, and measured the same drop-off again. The results and the rest of that onboarding work are in the trial-to-paid guide. [Doubling trial-to-paid at CodeAnt](https://www.utkarshdesign.com/guides/how-we-doubled-trial-to-paid): The full CodeAnt onboarding story, with every turn of the loop and the numbers. ## Where the double diamond fits The double diamond (discover, define, develop, deliver) is good vocabulary. It reminds a team to widen before narrowing, twice. The poster version is the problem, because it makes each diamond look like a month of work you do once. At a startup each diamond often takes days, and you go round many times. The loop above is the same shape, squeezed: "find the number" and "find the why" are the first diamond, the rest is the second. What the poster leaves out is the last step, measuring the same number again, which is the only part that tells you whether any of it worked. ## Where to start depends on the problem | Problem | Where the why usually is | Cheapest test | Where I met it | | --- | --- | --- | --- | | Signups don't activate | A step the user can't finish alone | A/B test of the step | CodeAnt's admin wall | | Support tickets pile up | A rule users learn too late | Move the rule earlier in a prototype | FamPay's one-time-use vouchers | | Users fail and try again | Errors that look alike | Five-user test on the failure screens | FamPay's payment timeouts and declines | | Managers can't decide fast | Data spread across views | One merged view, tested with managers | CodeAnt's manager dashboards | | Features ship slowly | Components rebuilt each time | Standardise the most repeated patterns | xPay's component library | Each of those has its own write-up on this site. The middle two columns are the useful part: once you know which kind of problem you have, you know where to look and how to test it cheaply. ## What each step leaves behind A process that leaves nothing written down repeats its arguments. Each turn of the loop should leave a few small artefacts in the team's workspace. - A one-line problem statement with the number and its current value. - The why, in one sentence, with the evidence linked. - The flow sketch that engineering agreed to. - The test result, even when it's "no change". - A decision log entry: what was chosen, what was rejected, and why. - The number again, two to four weeks after shipping. AI tools have shortened the middle of the loop. When a clickable Figma file can't show the behaviour, I build a working prototype with AI coding tools. They haven't changed the ends: finding the right number and checking it afterwards still need a person. ## Who should run the loop At a startup the loop needs one person who owns the number as well as the screens. My guide on product designer vs UX designer explains why that's usually the product designer. If you'd like me to run it with your team, the hire page has the details. ## Questions people ask ### How long does one turn of the process take? From a few days for a copy or state fix to a few weeks for a new flow. A single product area usually fits in about four weeks including a test round. ### Does a startup need user research before designing? It needs evidence, which can be a funnel, support tickets or five short calls. A formal research phase only pays off when you don't know who the user is. ### Is the product design process different from the UX design process? They share the steps. Product design adds the ends: choosing which problem is worth solving and checking the number afterwards. ### Can the same process work for a website redesign? Yes. The number becomes conversion or demo requests, and the cheapest test is often a single page rebuilt and compared. ## Sources 1. [The Double Diamond](https://www.designcouncil.org.uk/resources/the-double-diamond/), Design Council 2. [Why You Only Need to Test with 5 Users](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/), Nielsen Norman Group 3. [Installing a GitHub App from a third party](https://docs.github.com/en/apps/using-github-apps/installing-a-github-app-from-a-third-party), GitHub Docs ## Working on this? Tell me what you're building and where it's stuck: [book a 30-minute call](https://cal.com/utkarsh-design/30min), email [work@utkarshdesign.com](mailto:work@utkarshdesign.com) or [send a brief](https://www.utkarshdesign.com/contact). ## Related - [How we doubled trial-to-paid at CodeAnt](https://www.utkarshdesign.com/guides/how-we-doubled-trial-to-paid) - [Product designer vs UX designer vs UI designer](https://www.utkarshdesign.com/guides/product-designer-vs-ux-designer) - [How to run usability testing on a budget](https://www.utkarshdesign.com/guides/usability-testing-startups) - [Hire a product designer: freelance, contract or full-time](https://www.utkarshdesign.com/hire) --- Utkarsh Dhairya Panwar, Founding Product Designer and Design Engineer (IIT Roorkee; Founding Designer at CodeAnt AI, YC W24). Email: work@utkarshdesign.com · Book a call: https://cal.com/utkarsh-design/30min · Hire: https://www.utkarshdesign.com/hire · About: https://www.utkarshdesign.com/llms.txt