article-time-estimate-icon

4 minute read

Good Demo / Bad Demo

Matt Pollins

Matt Pollins

good demo
In this article

    At Lupl, we recently tore up our demo script. It had served us well enough…but something was missing. So, we ran some internal discussions on “Good Demo / Bad Demo” – a kind of retro on every demo we ever did, and every SaaS demo we ever attended. Our goal was to level up our demo and deliver something far more interactive and immersive.

    (Side note: If you want to see if we succeeded, Get a Demo here!)

    The outcome was a list of 10 good (and bad – mostly from me!) demo practices. In case it helps start a conversation about better demos in legal tech, we decided to open up our “Good Demo/Bad Demo” principles here. We still have PLENTY to learn, so whether you’re someone who regularly gives demos, or someone who regularly attends them, please feel free to radically disagree and post your thoughts in the comments…

    1. Good demos are immersive and interactive.
    Bad demos are a one-way lecture.

    Our biggest finding. What better way to show what a product can do (especially a collaboration product), than to actually bring the attendees into the product? At Lupl, we give people the option to hop right into the platform during the demo. It’s not mandatory but most people find they get way more out of it than with a passive experience. Bad demos feel more like a lecture, with a one way flow of product information from presenter to audience.

    2. Good demos tell a story. Bad demos are a list of features.

    Good demos have realistic users doing realistic things. You can immediately see how the product solves real problems for real people in the real world. Bad demos are a feature hit list, bouncing from one button or menu to the next. The features might be great but, in a bad demo, the work of envisaging those features to the real world is put on the audience.

    3. Good demos feel like they were built specifically for that audience. Bad demos feel generic.

    Good demos connect immediately with the audience because they were built specifically for that audience. It’s a real estate team? Make the demo about commercial lease matters. General Counsel? Show how the product gives them better visibility on outside counsel matters. Law firm partners? Show how it improves client relationships. This all depends on asking questions before jumping in. Bad demos are generic and could be for any audience. The presenter takes the user on a “tour” and hopes that something will interest them along the way. The balance here is getting the questions part right – because on the audience side, there’s rarely the time or patience to spend most of the call talking about themselves and not seeing the product.

    4. Good demos are short. Bad demos are long.

    Good demos are just the right length to get the job done and not a minute longer. The presenter manages the clock precisely and keeps things on track. There are no hard and fast rules here and every platform is different but, as a rule of thumb, if the demo part takes 45 minutes or longer, it’s probably IT training and not a demo.

    5. Good demos move slow. Bad demos move fast.

    This might sound like it contradicts the last point, but it doesn’t. You’ve seen your UI a thousand times but your audience has never seen it before. In a good demo, the presenter is moving much slower through the UI than s/he normally would. In a bad demo, the presenter is moving at full speed. The audience cannot follow and the cognitive load is way too much. This isn’t mutually exclusive with point 4 because you can have a brief demo and move at a reasonable pace. The next point is why.

    6. Good demos focus on a few things. Bad demos try to land Every. Single. Feature.

    People can take in far less information than you might want to convey to them in a single sitting. Good demos focus on a few things that the user can get done in the product. Bad demos spread themselves way too thin and leave attendees feeling overwhelmed.

    7. Good demos started three days before the demo. Bad demos started 3 minutes before the demo.

    To deliver on all the other things on this list (and, in particular, tailoring demos for the audience), good demos need preparation. You can’t overestimate the planning that goes into a good demo. Bad demos are rushed – you can tell the presenter just finished their last call three minutes ago and barely knows who they’re speaking to. A common sign is that they spend the first few minutes getting things set up and figuring out how to screenshare!

    8. Good demos take questions but stay on track. Bad demos never get out of the weeds.

    You’re 2 minutes into your demo and you get an “into the weeds” question about cloud infrastructure. That’s great because it shows someone is listening! At this point, good demos briefly answer the question but stay on track. Bad demos delve right into the weeds and then rush the actual demo part in 5 minutes. This is about reading the room. If the call is with the cloud infrastructure team, a deep dive may be just the thing. If you’ve got a mix of IT, lawyers and business development folks, the odds are that not everyone wants the deep dive on cloud infrastructure. Don’t alienate the whole audience by going too deep on one topic. You can always park items and follow up later.

    9. Good demos use mobile and desktop. Bad demos just use desktop.

    Guess how lawyers typically start their day? On their phone! That’s right, like the rest of the human population, most lawyers will pick up a mobile device and start triaging their day before they’re at their desk. Good demos leverage mobile screenshare tools and demo the full mobile experience. Bad demos focus on desktop because that’s just easier. If your real-world users are going to use your app on mobile, don’t exclude mobile from the demo just because mobile screensharing is harder.

    10. Good demos are substance and style. Bad demos are just substance.

    Plenty of legal tech demos are all substance and no style. Of course, substance is the table stakes, but why can’t a demo be fun too? We’ve tried a few things to jazz up our demos – we used the characters from Suits. We had a Star Wars theme for a while, including a “Termination of Jar Jar Binks Employment” matter (sorry, Jar Jar Binks fans, if you’re out there). Make it fun because in a world of Zoom and Teams, you’re competing with attendees’ urge to multi-task by checking their emails.

    We’d welcome any and all feedback in the comments. And, if you haven’t already, don’t forget to schedule a Lupl demo today and let us know whether we deliver!

    In this article

      More legal tech insights we think you'll love

      The cost of over-dependence on AI

      AI saves us time, boosts productivity, and lets us do...

      # Lupl Workstream Design Principles: A Practical Guide to Legal Project Management for Lawyers Legal project management works when your setup is simple, ownership is clear, and statuses are unambiguous. This guide shows how to turn existing processes and checklists into a lean, reliable Workstream. Lupl is the legal project management platform for law firms, making it easy and intuitive to apply these principles. It also supports moving your work from Excel, Word tables, or if you are transitioning from Microsoft Planner, Smartsheet, or Monday. You will learn what belongs in a Workstream, a Task, or a Step, and which columns to use. If you want practical project management for lawyers, start here. **Excerpt:** Legal project management works when ownership, dates, and statuses are clear. This guide shows lawyers how to turn checklists into Lupl Workstreams with the right columns, Tasks, and Steps. Use it to standardize project management for lawyers, reduce follow ups, and move matters to done. --- ## How to organize your work with Workstreams, Tasks, and Steps Workstreams, Tasks, and Steps are three different types of objects in Lupl. They form a simple hierarchy. Workstreams contain Tasks. Tasks may contain optional Steps. This hierarchy aligns with standard project management. In project management, you break work into projects, deliverables, and subtasks. Lupl adapts this for lawyers by using Workstreams, Tasks, and Steps. This makes it easier to map legal processes to a structure that teams can track and manage. * **Workstream.** Use when you have many similar or related items to track over time. Think of the Workstream as the table. * Examples: closing checklist, court deadlines, pretrial preparation, regulatory obligations, due diligence, local counsel management. * **Task.** A high level unit of legal work. A key deliverable with an owner and a due date. Tasks are the rows. * Examples: File motion. Prepare Shareholder Agreement. Submit Q3 report. * **Step.** An optional short checklist inside a single Task. Steps roll up to the parent Task. * Examples: Draft. QC. Partner review. E file. Serve. ### Quick test * If it can be overdue by itself, make it a Task. * If it only helps complete a Task, make it a Step. * If you need different columns or owners, create a separate Workstream. --- ## Do you need to track everything in Lupl Not every detail needs to be tracked in a project management system. The principle is to capture what drives accountability and progress. In Lupl, that means focusing on deliverables, not every micro action. * Use the level of detail you would bring to a weekly team meeting agenda. * Position Tasks as key deliverables. Treat Steps as optional micro tasks to show progress. * Example: You need client instructions. Do not add a Task for "Email client to request a call." Just make the call. If the client approves a key deliverable on the call, mark that item Approved in Lupl so the team has visibility. --- ## Start with the Core 5 columns Columns are the backbone of a Workstream. They define what information is tracked for each Task. In project management terms, these are your core metadata fields. They keep everyone aligned without overcomplicating the table. Keep the table narrow. You can add later. These five work across most legal project management use cases. 1. **Title.** Start with a verb. Example: File answer to complaint. 2. **Status.** Five to seven clear choices. Example: Not started, In progress, For review, For approval, Done. 3. **Assignee.** One named owner per row. If you add multiple assignees for collaboration, still name a primary owner. 4. **Due date.** One date per row. 5. **Type or Category.** Show different kinds of work in one table. Example: Filing, Discovery, Signature, Approval. **Priority.** Add only if you actively triage by priority each week. If added, keep it simple: High, Medium, Low. --- ## Add up to three Helper columns Lupl includes a set of pre made columns you can use out of the box. These allow you to customize Workstreams around different phases or stages of a matter. They also let you map how you already track transactional work, litigation, or other processes. Helper columns are optional fields that add context. In task management, these are similar to tags or attributes you use to sort and filter work. The key is to only add what you will update and use. Pick only what you will use. Stop when you reach three. * Party or Counterparty * Jurisdiction or Court * Phase * Approver * Approval, status or yes or no * Signature status * Risk, RAG * Amount or Number * External ID or Client ID * Document or Link * Docket number * Client entity **Guidance** * For Task Workstreams, prefer Approver, Approval, Risk. The rest are more common in Custom Workstreams. * Aim for eight columns or fewer in your main table. Put detail in the Task description, attachments, or Steps. --- ## Simple rules that keep your table clean Consistency is critical in project management. A cluttered or inconsistent table slows teams down. These rules ensure your Workstream remains usable and clear. * Only add a column people will update during the matter. If it never changes, set a default at the Workstream level or set a default value in the column. * Only add a column you will sort or filter on. If you will not use it to find or group work, leave it out. * If a value changes inside one Task, use Steps. Steps show progress without widening the table. * Keep columns short and structured. Use Description for brief context or instructions. Use Task comments for discussion and decisions. Link to work product in your DMS as the source of truth. * One accountable owner per Task and one due date. You can add collaborators, but always name a primary owner who moves the Task. If different people or dates apply to different parts, split into separate Tasks or capture the handoff as Steps. * Add automations after you lock the design. Finalize columns and status definitions first. Then add simple reminders and escalations that read those fields. --- ## Status hygiene that everyone understands Status is the single most important column in project management. It tells the team where the work stands. Too many options cause confusion. Too few cause misalignment. In Lupl, keep it simple and consistent. * Five to seven statuses are enough. * Use one review gate, For review or For approval. Use both only if your process needs two gates. * One terminal status, Done. This is the end state of the Task. Use Archived only if you report on it or need it for retention workflows. --- ## When to split into multiple Workstreams In project management, it is best practice to separate workstreams when workflows, owners, or audiences diverge. Lupl makes this easy by letting you create multiple Workstreams for one matter. Create a new Workstream if any of the following are true. * You need a different set of columns for a chunk of work. * Ownership or cadence is different, for example daily docketing vs monthly reporting. * The audience or confidentiality needs are different. **Signal** * If half your rows leave several columns blank, you are mixing processes. Split the table. --- ## Decision tree, three quick questions Use this quick framework to decide where an item belongs. This is the same principle used in task management software, adapted for legal workflows. 1. Is this a list of similar items over time, or a discrete phase of the matter * Yes. Create a Workstream. 2. Can it be overdue by itself, and does it need an owner * Yes. Create a Task. 3. Is it a step to finish a Task and not tracked on its own * Yes. Create a Step. --- ## Common mistakes to avoid Many project management failures come from overdesigning or misusing the structure. Avoid these mistakes to keep your Workstreams lean and effective. * Wide tables with many optional columns. Keep it to eight or fewer. * Two columns for the same idea, for example Status and Phase that overlap. Merge or define clearly. * More than one approval gate when one would do. It slows work and confuses owners. * Mixing unrelated processes in one table, for example signatures and invoice approvals. --- ## Build your first Workstream Building a Workstream is like setting up a project board. Keep it light, pilot it, then refine. Lupl is designed to let you do this quickly without heavy admin work. 1. Write the Workstream purpose in one sentence. 2. Add the Core 5 columns. 3. Add at most three Helpers you will use. 4. Define clear Status meanings in plain words. 5. Set defaults for any value that repeats on most rows, for example Jurisdiction. 6. Add two light automations, a due soon reminder and an overdue nudge. 7. Pilot for one week and adjust. --- ## Where this fits in legal project management Use these principles to standardize project management for lawyers across matters. Keep structures consistent. Reuse column sets and status definitions. Your team will find work faster, reduce follow ups, and close loops on time. --- ### On page SEO helpers * Suggested title tag. Lupl Workstream Design Principles, Practical Legal Project Management for Lawyers * Suggested meta description. Learn how to design lean Lupl Workstreams for legal project management. Get clear rules for Tasks, Steps, statuses, and columns to run matters with confidence. * Suggested URL slug. legal-project-management-for-lawyers-workstream-design

      Lupl Workstream Design Principles: A Practical Guide to Legal Project Management for Lawyers

      Learn why large‑firm lawyers are ditching Excel checklists for dynamic,...

      Do AI Agents Have An Identity? Notes from InfoSec Discussions

      Agentic AI is in its early phases but advancing fast....