[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-planning-an-mvp-pilot":3,"blog-post-adjacent-planning-an-mvp-pilot":69},{"id":4,"title":5,"slug":6,"excerpt":7,"cover":8,"coverAlt":13,"datePublished":14,"dateModified":14,"category":15,"author":19,"tags":26,"answerFirst":31,"keyTakeaways":32,"body":39,"faqs":40,"sources":59,"relatedServices":60,"seo":64},"av7p5uv5zbl1ymz87gxx54pf","Planning an MVP Pilot: Write the Learning Plan Before the Launch Date","planning-an-mvp-pilot","A pilot is the first time a product meets people who did not help design it. Decide what it should teach, who is in it, and what counts as a result before the first invite goes out.",{"url":9,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fdays_day_07_export_blog_16x9_565a485252.jpg",2400,1350,null,"Planning an MVP Pilot: Users, Feedback, Success Criteria","2026-09-22",{"name":16,"slug":17,"description":18,"seo":12},"Engineering","engineering","Software architecture, code quality and the engineering practice behind the systems we build.",{"name":20,"slug":21,"entityType":22,"role":23,"bio":24,"credentials":12,"photo":12,"profiles":25},"DrieVerse Tech","drieverse-tech","organization","Engineering Team","DrieVerse Tech is a software design and engineering studio. Case studies and posts published under this byline reflect the team's collective work, reviewed before publication.",[],[27,29],{"name":28,"slug":28},"decision-frameworks",{"name":30,"slug":30},"process-design","Planning an MVP pilot means deciding what it has to teach before anyone is invited: two or three questions, and the result that would mean carry on, change course, or stop. Then choose users who have the problem today, watch their onboarding, agree the boundaries in writing, treat support as research, observe behaviour before asking opinions, and make the decision on a date fixed in advance.",[33,34,35,36,37,38],"A pilot needs a learning plan, not just a launch date. Write down two or three questions it must answer, and the result that would mean carry on, change course, or stop, before anyone is invited.","Set the thresholds before the data arrives. Once people are using the product, almost every number can be read as encouraging.","Invite people who have the problem now and a workaround they use today. The workaround is the benchmark the product has to beat.","Onboarding is the first thing a pilot tests. Watch the first few users set up without steering them, and record every hesitation.","Log every support request with what the user was trying to do. The support log is often more honest than the feedback interview.","An extension without a new question is a delay. If the results are ambiguous, sharpen the question and run a second short pilot.","Most MVP pilots are planned around a date. The build is scheduled to finish,\nthe first users are lined up for the week after, and the plan ends there. What\nhappens during the pilot, and what would count as a result, is left to be\nworked out once people are using it.\n\nThat order is backwards. A pilot is the first time the product meets people\nwho did not help design it, and it is short. If nobody decided in advance what\nit was meant to establish, the weeks produce impressions rather than evidence,\nand the decision at the end gets made on whichever user was loudest.\n\nA pilot needs a learning plan, not just a launch date. The plan has six parts:\nwhat the pilot should teach, who is in it, how they get started, what the\nboundaries are, how they get help, and how you hear from them. Then a\ndecision, on a day chosen before the first invite goes out.\n\n## What should the pilot teach you?\n\nWrite down two or three questions, no more. Each should be something the team\nis genuinely unsure of, and each should change what gets built next depending\non the answer. For example:\n\n- Will people who have this problem finish setting up without help?\n- Do they come back in the second week without a reminder?\n- Is the part we think is the core the part they actually use?\n\nThese usually descend from the question the MVP was scoped to answer in the\nfirst place, which is how we approach\n[building an MVP without building the wrong thing](\u002Fsolutions\u002Fstartup-acceleration).\nThe pilot is where that question finally meets real use.\n\nFor each question, write down what result would mean carry on, what would mean\nchange course, and what would mean stop. Do it now, before any data exists.\nOnce people are using the product, almost every number can be read as\nencouraging, and a threshold chosen afterwards tends to land just below\nwhatever happened.\n\nLeave sign-up counts off the list. How many people joined measures how well\nthey were invited, not whether the product works for them.\n\n## Who to invite, and who to leave out\n\nInvite people who have the problem now and are handling it some other way\ntoday: a spreadsheet, a shared inbox, a manual routine somebody resents. Their\ncurrent workaround is the benchmark. The pilot is answering whether the\nproduct beats it, and they are the only people who can tell you.\n\nLeave out friends, family, and investors. They are generous testers and\nunreliable evidence, because they want it to work. Leave out anyone whose main\nneed is a feature that was deliberately cut; they will spend the pilot testing\nwhat is missing. And leave out anyone whose participation rests on a promise\nmade to win them, because their feedback is about the promise.\n\nKeep the group small enough that the team can speak to every person in it,\nand large enough that one person's habits are not mistaken for a pattern.\nRecruit a few more than you need. Some will never start, and that is a finding\ntoo.\n\n## Onboarding is the first thing you are testing\n\nThe first session is where pilots lose people, and it is the part teams\nrehearse least, because the team no longer sees it. Everyone building the\nproduct set it up months ago.\n\nOnboard the first few users yourselves, on a call, watching rather than\nsteering. Note every point where they hesitate, ask a question, or do\nsomething nobody expected. Resist the urge to explain. Every explanation you\ngive is one the product will not be there to give later.\n\nThen fix what the first sessions exposed and let the next users set up on\ntheir own, with only what a real customer would receive. That second group\ntells you whether the fixes held. The measure worth tracking is the time from\ninvitation to the first useful result, not the time to an account existing.\n\n## Boundaries that protect the users and the result\n\nPut the terms in writing before anyone starts, in plain language:\n\n- How long the pilot runs, and the date it ends\n- What the product does and does not yet do\n- What data participants put in, where it is held, and what happens to it\n  when the pilot ends\n- Whether they can keep using the product afterwards, and on what terms\n- How either side can end it early\n\nThe team needs a boundary too: no features built for one pilot user during\nthe pilot. A request is valuable data. Building it midway changes the\nexperiment, and the results no longer describe the product you set out to\ntest. Log the request, and bring it to the decision.\n\n## Support is a research channel with a response time\n\nGive pilot users one channel, a stated response window, and somebody actually\nwatching it. Then log every request with a note of what the person was trying\nto do when they got stuck.\n\nThat log is often more honest than any interview. People report what blocked\nthem in the moment, not what they remember a fortnight later with the\nfrustration worn off. Read it weekly and group it. The requests that repeat\nare the findings.\n\nOne caution. Pilot users usually get far more attention than paying customers\nwill, and that attention quietly improves the results. Note which outcomes\ndepended on the team stepping in, so the decision accounts for the help that\nwill not scale.\n\n## Watch what people do, then ask about it\n\nOpinions about a product are unreliable; behaviour is less so. From the first\nday, record the handful of actions that map to the pilot's questions: setup\ncompleted, first useful result, return visits, the core action used or\nignored. Tracking added in week three loses the weeks that mattered most.\n\nThen hold short conversations at fixed points, one after the first week and\none near the end, and ask about specific, recent use. \"Walk me through the\nlast time you used it.\" \"What did you do instead, the week you did not?\"\nSpecific questions get specific answers.\n\nAvoid \"would you use this\" and \"what features should we add\". The first is\nanswered politely. The second produces a wish list, not a finding. One\nquestion worth asking everyone: if this disappeared tomorrow, what would you\ngo back to?\n\n## Decide on the day you fixed in advance\n\nA pilot ends in one of three decisions, made against the thresholds written\nat the start.\n\n**Carry on.** The questions came back the way the criteria said they should.\nWiden access, and expect the next stage to test the parts built for a small\ngroup. That is when first-release architecture gets its real test; we wrote\nabout that decision in\n[monolith or microservices for your first release](\u002Fblog\u002Fmonolith-or-microservices-for-your-first-release).\n\n**Change course.** Something specific was learned and points at a specific\nchange. Make it, then run a second short pilot with a sharper question.\n\n**Stop.** The product did not beat the workaround, and nothing in the logs\nsuggests a change that would. This is a result, reached in weeks rather than\nafter a year of building on the assumption.\n\nThe pilot that quietly gets extended because the results are unclear is the\ncommon failure. An extension without a new question is a delay. If the answer\nis ambiguous, the question was probably too loose, and the fix is to sharpen\nit, not to wait longer.\n\nIf a first launch is coming up and its plan currently ends at the launch date,\nthis is the part worth settling now, while the questions can still shape who\ngets invited. Discuss the first launch with us before the first invite goes\nout.",[41,44,47,50,53,56],{"question":42,"answer":43},"What is an MVP pilot?","An MVP pilot is a limited, time-boxed release of a minimum viable product to a small group of real users, run to answer specific questions before a wider launch. It differs from a launch because it has a fixed end date, a chosen group of participants, and success criteria written down in advance, so the result is a decision rather than a general impression.",{"question":45,"answer":46},"How do you define success criteria for an MVP pilot?","Write two or three questions the pilot must answer, such as whether users finish setup without help or return in the second week. For each, decide before launch what result means carry on, what means change course, and what means stop. Thresholds set after the data arrives tend to be set just below whatever happened.",{"question":48,"answer":49},"Who should be invited to an MVP pilot?","People who have the problem now and are handling it with a workaround today, such as a spreadsheet or a manual routine, because that workaround is the benchmark. Avoid friends, family, and investors, whose goodwill skews the evidence, and anyone whose main need is a feature that was deliberately left out of the first version.",{"question":51,"answer":52},"How many users should an MVP pilot have?","Few enough that the team can speak to every participant personally, and enough that one person's habits are not mistaken for a pattern. The right number depends on the product and the questions being tested. Recruit a few more than needed, because some invited users never start, and that drop-off is itself useful evidence.",{"question":54,"answer":55},"How do you collect useful feedback during a pilot?","Record behaviour from the first day: setup completion, time to the first useful result, return visits, and whether the core feature is used. Then hold short conversations at fixed points and ask about specific recent use, such as walking through the last session. Questions about hypothetical future use are answered politely and reveal very little.",{"question":57,"answer":58},"What should happen at the end of an MVP pilot?","A decision on a date fixed in advance, made against the criteria written before launch: carry on and widen access, change something specific and run another short pilot, or stop. Extending a pilot because the results are unclear usually means the question was too loose, so sharpen the question rather than waiting longer.",[],[61,62,63],"software-development","app-development","it-consulting",{"metaTitle":13,"metaDescription":65,"ogImage":66,"canonicalPath":12,"noindex":68},"How to plan an MVP pilot: set success criteria first, choose the right pilot users, watch onboarding, agree boundaries, and decide on a date fixed in advance.",{"url":67,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fdays_day_07_export_blog_16x9_11c42a28a0.jpg",false,{"prev":70,"next":12},{"id":71,"title":72,"slug":73,"excerpt":74,"cover":75,"coverAlt":77,"datePublished":78,"dateModified":78,"category":79,"author":80,"tags":81},"ncxjd94c3l20meh2j5irhwas","Taking Over a Software Project: What the Business Must Own","taking-over-a-software-project","The code is the easy part to recover. Before an outgoing team stops answering, secure the repository account, the signing keys, the domain, the deployment path, and the known issues list.",{"url":76,"width":10,"height":11,"alt":12},"https:\u002F\u002Fmedia.drieverse.com\u002Fdrieverse-media\u002Fcms\u002Fdays_day_06_exports_drieverse_b06_blog_16x9_2400x1350_36986e2bbe.jpg","Taking Over a Software Project: What to Secure","2026-09-21",{"name":16,"slug":17},{"name":20,"slug":21},[82,84],{"name":83,"slug":83},"risk-management",{"name":30,"slug":30}]