Building Legal Apps: Defining the Scope

There are several next steps to be taken before building.  Having chosen the right model, above, you next want to gather the right tools to help you with your build.  You also want to have the right process --- the way to think through how to build.

Most importantly, you want to know your users, by stepping into their shoes to learn their wants and needs. You also want to take a look at the competition. And to identify the problem that needs solving, and then work backwards. Only after you’ve done this research should you start to build a prototype. After that, you’ll want to seek feedback from users to improve your product until you’ve got a winning product that users will consider worth the expenditure of their resources. We now discuss each of these in detail

Scope Out The Project To Build A Minimum Viable Product First

After you’ve done your user research, it’s time to carefully define the scope of your product.  When building automated documents, the scope of the project is simple:  It’s what to automate.  The key here is to start simple and small as to your features.  In fact, it’s so important to start small that you should first focus on making a “minimum viable product”,  which is a product with enough utility to attract early users, but which does not have every bell and whistle.  You can add more features as you iterate the product after user feedback, as discussed below.  You can also increase the subject matter scope as you iterate.  For example, you can expand into additional states and add more types of legal documents.

For all of this, using the right software to help you plan and prototype your first build is essential.  Tools like Documate will allow you to do rapid prototyping and help you understand what you need to change as you iterate, which saves you from inefficiently spending money and time.

During all of this, you continue your objective research and let that drive your decisions.  In other words, don’t commit to a specific product version or plan at the start --- rather, only commit once you’ve done user research, and validated it with user feedback, so that you fully understand what it will entail to make a successful first minimum viable product.

In your planning to build your first minimum viable product, you want to prioritize features based on the user’s most basic needs, in order to be clear about what features the first minimum build should have.  This will help you build a test product that you can get to get clients fast, so they can start using the product as soon as possible.  

One way to do this is through a “lean prioritization” analysis, in which you put the potential features of your build into four categories --- Quick Wins (high value, low effort), Big Bets (high value, high effort), Maybes (low value, low effort), and Time Sinks (low value, high effort).  Cut away the time sinks as soon as you identify them.  In addition to making a “lean prioritization” matrix, you may also want to use something like LucidChart to map out your process.

Once you’ve done the above research and you’ve come up with estimates for the time and money to be invested into your build, stick to them. Be rigorous. For example, in his book “Inspired: How to Create Tech Products People Love”, Marty Cagan calls his focus a “high-integrity commitment.”

Continue Market Due Diligence Before, During, And After

Before, during, and after all of the above, be sure to do your market due diligence. You need to know what the existing solutions are, and you need to be able to show how you’re doing it better. You should incorporate this information into your planning process, your first minimum viable product, and in all subsequent iterations.

Make Sure You Have Budget and Business Sustainability -- For You and Your Users

As the builder of your automated product, you need to make sure that you have a strong business case for it --- that your product is sustainable from a financial perspective for both you and your users. This speaks not only to your own budget and finances, but also the budgets and finances of your users: Will the acquisition cost of your product make business sense for the various user personas that you’ve created above --- and for your real users? Take into account the available revenue and budgets of both for-profit companies and of non-profits (for example, take into account their grants). Like market due diligence with respect to your competitors, your user due diligence should take place before, during, and after your first build.

After you’ve taken the above steps and are ready to build your first minimum value product, it will be time to build and, after that, it will be time to gather more user feedback, plan and build your next iteration, and then launch version 2.0 of your legal product.  These steps will be discussed in the next article in this series.