Nolo and WillMaker
Nolo helps consumers and small businesses find answers to everyday legal questions. They provide a range of legal products, primarily to the US market. Included in their offering are "do-it-yourself" (DIY) products. These include legal forms, online documents, and the like. Users fill out an "interview" (a form-based series of pages) then are given a legal product. This product is usually a document such as a will, an LLC application, or divorce proceedings.
Nolo also operates WillMaker - America's #1 estate planning software. WillMaker helps people plan their estate. It helps them create documents like wills, living trusts, healthcare directives, and more.
Technical discovery: The initial situation and Nolo's objectives
When we started work with Nolo, the ask was to figure out what to do with the software powering their DIY products. To learn more about the situation, we decided to start with a Technical Discovery. Performing this discovery would allow us to understand the true nature of the existing software, and give Nolo better advice on how best to proceed.
The software was a mature web application written in Groovy. There weren't many people in the organization who knew how to maintain it. Those who did were moving to other roles. Nolo called this type of software a "form builder".
The existing software lacked features that prevented it from powering more complex products. A sore point was that it couldn't support WillMaker's complex interview workflows. WillMaker was only available as a desktop application - Nolo wanted to bring it to the web.
Nolo's objectives were:
- Establish a long-term technical solution for DIY products.
- Use this solution to create a web-based version of WillMaker.
What to do with the existing form-builder solution was also a concern. Should we:
- keep it, learn how to maintain it then extend it to support WillMaker?
- replace it with an off-the-shelf alternative?
- replace it with a platform that we build ourselves?
The choice we'd make here would determine the service we'd perform next. Keeping the existing solution would mean a Legacy Application Modernization. Replacing it with an off-the-shelf alternative would mean helping Nolo with a migration. Building ourselves would mean a Brownfield Development project.
Getting the foundations right from the start
We were to help Nolo answer the above questions, then help them implement the chosen solution. This was to be a long-term relationship.
We also understood that there were many people at Nolo interested in the outcome of this project. A form builder capable of powering WillMaker was a potential game-changer. It would have implications beyond just this product.
So we didn't jump in and start coding right away. Instead, we felt it important to establish a framework to keep us grounded as we made progress. Something suitable for the situation surrounding the work we would be doing.
First, we decided to use Scrum to organize our team and our work. The cadence of fixed-length Sprints would provide regular progress in predictable increments. Sprint Reviews would provide a time for stakeholders to learn about project developments.
We were a remote team and we were remote from Nolo (who are based on the US Pacific Coast). So we made written communication central to how we operated. First we created a central document to be the go-to place for information about the project. This detailed the following:
- A project charter, outlining the high-level purpose of the project and the current state.
- Who the team members were and their contact details.
- Who the primary stakeholders were.
- Where the project roadmap, product backlog, and Sprint board were.
- Links to artifacts we produced, like research documents or recorded presentations.
We would send anyone interested in the project to this document. This would allow them to learn and discover about it on their own. If someone had a question that the document didn't cover, we'd provide an answer by way of updating the document.
Our initial team was two Software Engineers (SE) and one part-time Product Manager (PM). The PM assumed the role of Product Owner on the Scrum team and one of the SEs assumed the role of Scrum Master.
At this point, we were well grounded and ready to get stuck in.
Solutions evaluation: Many possible approaches
Our first goal was to decide what to do with the existing form builder. We considered each question in the list above in turn.
Keep it?
We decided to evaluate the effort needed to modernize the existing solution. To do this, we spent some time contributing to it. We fixed some open bugs, improved a few features, and learned how to deploy the application.
It became clear that keeping the solution was a no-go. The original creators of the software had chosen Groovy as the implementation language. At the time Groovy was a promising new technology. But it hadn't stood the test of time. It had become a niche language with a marginal ecosystem to support it. Language updates and supporting libraries were sparse and couldn't be relied on.
The application itself needed major upgrades. The architecture of the code wasn't able to support the features we needed to build WillMaker. And the admin user experience hindered Nolo product editors from working efficiently. The case to keep the existing solution was non-existent.
Off-the-shelf alternative?
Our next question was: could we replace it with an off-the-shelf alternative?
This was a fair question. We were talking about a software application that was generic in nature. It was a form builder, and there are many form builders on the market. Could we find one to suit our needs?
The process we followed to find a suitable candidate was:
- Create a shortlist of possibilities.
- Do a quick "surface level" evaluation each to gauge suitability.
- Identify the most promising candidate.
- Build a proof of concept (POC) with the most promising candidate.
If our first choice turned out to be unsuitable, we'd consider building a POC of the second candidate.
We compared six candidates and decided that the most promising was one based on SurveyJS.
Our features comparison summary
We built a POC of the form builder using SurveyJS but found it unsuitable. The features needed for WillMaker were much more complicated than what SurveyJS offered. We would have to significantly extend SurveyJS - something we didn't think was sensible. No other candidate came close to SurveyJS, so we decided not to try another. We had, in essence, concluded that an off-the-shelf solution was a no-go.
Build ourselves?
Having eliminated the other options, we decided to write the form builder ourselves. The engagement had become a Brownfield Development project. But we weren't ready to leave evaluation mode just yet. We had to determine the stack we would use.
Users would navigate a series of forms, oftentimes on their mobile devices. So we decided to build a single-page application (SPA) with a mobile-first design. We based the frontend stack on React to help us keep a complex user interface organized.
When it comes to backend development, at Hivekind we prefer to use Ruby on Rails. This wasn't appealing to Nolo as their other applications are mostly written in PHP. So for the backend, we decided to use Laravel. Laravel is an MVC framework for PHP which is much like Rails, so we felt comfortable using it. We chose GraphQL as the basis of our API, as we expected large, nested payloads to come in from the frontend.
With the technical direction set and our tech stack chosen, we started implementation.
A new forms platform and its first product
As we got started, we had to take note of and coordinate with several adjacent teams at Nolo.
The full application was more complicated than just a form builder. The major user workflow when using DIY products was:
- Complete an "interview" (via forms from the form builder) to gather necessary information.
- Receive a "document", based on the information gathered from the interview.
So our application had to support both the interview workflow and document generation. The interview would come from the form builder. The document generation hadn't been deeply considered.
On top of this, non-technical admin users were to create the interviews. These were Nolo legal experts who knew what information to collect for each product. We needed an admin interface to design interviews and manage products.
Nolo's design team created the UI/UX designs for us. They were in the form of hi-fi mockups created in Figma. These designs were not all created upfront. The initial parts of the application were designed based on what we were going to work on first. As the project progressed the design team supplied us with further designs as we needed them.
We knew upfront that the interview workflow was the highest priority piece. But given that non-technical users would use the admin tool, we constrained our approach. Config files would be used to define all interviews. Such config files would be passed to the frontend and used to render the interview forms. If the frontend worked in this way then we could build an admin tool to generate this config later.
Our goal during this phase was to implement a simple Nolo product. The promissory note was what we chose.
Focusing on WillMaker Online
As the new forms builder started taking shape, project objectives were oriented to WillMaker. Up until this point, our major driver was: "we are building a forms platform". But the major prize from a business standpoint was having an online version of WillMaker. We decided to change our major driver to: "we are building WillMaker Online".
But why do this? WillMaker Desktop is a good product. It supports all the use cases needed for estate planning and has been successful for decades. Why build an online version of it?
The answer wasn't to do with functionality. There weren't features missing from Desktop that only an online implementation could provide. Rather, it was strategic advantages that were driving us. WillMaker Online would enable
- different payment options, including subscriptions
- access on mobile devices
- bundling with non-WillMaker products
- all users getting new features as soon as they're released
Our goal wasn't to cannibalize Desktop per se. It was to make a complementary product that would take advantage of these strategic options down the road.
Minimum viable product: Development driven by WillMaker features
When carrying out a Brownfield project, we build a new product to replace an existing one. The first step is to build a Minimum Viable Product (MVP). The scope of the MVP is inspired by the existing product, oftentimes by the most pressing existing pain points. As work on the new forms platform progressed, we were gradually honing in on the scope of our MVP.
The overarching goal was for the MVP to provide WillMaker products. But we needed a strategy by which to approach the WillMaker implementation. We figured that knowing that the platform had all the necessary features was the first step. Once we knew that, we could build the full solution later. So we began prioritizing the features of the platform that WillMaker needed.
The WillMaker product allows its customers to produce several legal documents. These include:
- Wills
- Living Trusts
- Healthcare Directives
- Durable Power of Attorney for Finances
- Letters to Survivors
- Transfer on Death Deeds
To build WillMaker is to build all these "standalone" products, then bundle them as one package. We chose to focus on the Will first. This was because the Will needed many of the features the other products needed too.
Mini will
But even taking on the Will was a major chunk of work. We wanted to set ourselves a goal that was achievable in a shorter time frame, so we decided to implement a "Mini Will".
We set the scope of the Mini Will according to three principles:
- It must use all the platform features that the Will would use.
- It must not make repetitive use of such platform features.
- It should show a coherent experience of creating a Will.
The first point ensured we could create the (full) Will in a later iteration. The second point allowed us to complete the Mini Will with as small a scope as possible. The third point would let stakeholders see what the platform was capable of.
We went on to build the Mini Will. The platform proved capable, and we showed stakeholders that it had the ability to create a Will. This was an important moment. Up until this point, there was some doubt that creating WillMaker on a form builder was possible. When we demonstrated the Mini Will these doubts disappeared. It was a turning point, where consensus went from "can we do this?" to "we're doing this!".
The WillMaker Online roadmap
The turning point was, in fact, more fundamental. There became a widespread desire to ship WillMaker Online. The question on everyone's lips was: when can we launch?
We are always careful when making estimates. The future is uncertain, and we don't like to accidentally provide inaccurate information. Doing so can cause others to make plans which rely on such information becoming true.
So instead of giving a direct answer to the question, we took a different approach. We made as much information about the project available as possible. Then we shared different timelines based on choices we could make about the project scope.
We shared this through a project roadmap. We continually kept this roadmap up to date. This made sure that the latest information was available to everyone interested.
A slice of our roadmap, which we created using Miro
The roadmap helped us with some strategic aspects of the project:
- Seeing that building WillMaker Online was to build several standalone DIY "form" products.
- Estimating forms we hadn't started could be done quite accurately. Estimates of forms we'd already completed provided a good yardstick.
- We started seeing where the gaps in our thinking were. Included in this were the interface points with other systems at Nolo. We could figure out what we needed from other teams - teams that managed the systems we would interface with.
- We plotted a course to WillMaker Online launch. This would later include deciding to build some features after launch.
Team composition changes
When we decided to go all out on pursuing WillMaker Online, we expanded our team. We grew to four SEs and one dedicated (full-time) PM.
We had been practicing Scrum since the beginning. Our biweekly Reviews had become a much-anticipated highlight on the Nolo calendar. The shift in focus had caused the nature of our PM's work to expand into general strategy at Nolo. To counter this shift, the SEs on our team took on the work to create technical tasks for our backlog. This meant our PM could focus on user story creation. Our Product Backlog was always sufficiently populated ahead of Grooming and Sprint Planning.
Last proof of technical fitness: The Living Trust
The second form in the WillMaker suite is the Living Trust. The Living Trust's interview isn't as complicated as the Will's. But another factor made its technical implementation the most challenging of them all.
The interview logic had to be accessible to users in different "modes''. First, the trust is created (via creation mode). Later it can be amended (amendment mode) or restated (restatement mode). It can also be revoked (revokement mode). Completing the interview in these different modes produces different documents. Each mode also changes the interview in subtle ways.
Stakeholders felt that if we could support the Living Trust, the platform could do anything. Within our team, we had been confident we could implement it from the start.
With time we built the major technical aspects of the Living Trust. Remaining skepticism of the fitness of the platform evaporated. Now it was time to put our heads down and get to launch.
An Interim launch: The full online will
At this point, we were building the full suite of forms necessary for WillMaker Online. But we weren't happy with the idea of a "big bang" release of everything all at once. We wanted to put a smaller increment out into the market. This would:
- verify that real customers were willing to pay for the product we were creating.
- force us to complete the "plumbing" (integration with other services) necessary to launch.
The idea behind the second point was that we wanted an "excuse" to do the integration work. This would cause us to catch any unforeseen obstacles early.
We chose to release the Will part of WillMaker Online. We called this the "Full Online Will".
To launch the Full Online Will we had to integrate with Nolo's storefront. We created a product page which guided potential customers into a purchase flow. We also integrated with Nolo's payments system.
We did indeed encounter some unforeseen obstacles while doing this. We were glad to have sorted them out far ahead of the larger WillMaker Online launch which was coming later.
Target launch date and "flexing the scope"
By this point we had completed:
- The Will
- A part-way implementation of the second form: the Living Trust
- Some groundwork on the third form: the Healthcare Directive
On top of completing these second and third forms, we had three un-started forms to go.
There was mounting pressure to set a launch date. Collectively, we wanted to bring customers on board and plan marketing activities. But the remaining scope of work remained substantial and it wasn't feasible to lock in a target date yet. This situation started to cause some tension between stakeholders. What to do?
At the center of the discussion was a desire for something impossible. To set a launch date (six to nine months out), and implement the full scope of WillMaker Online in that timeframe.
The reality of the situation was that we could have one but not both. Either we set a launch date and flex scope to meet it, or fix the scope and accept a longer-term, non-determined date.
We advocated for flexing the scope of the product. We wanted to achieve Earliest Usable Product. We identified what parts of WillMaker could be released after the initial launch. We also nominated dedicated QA and UAT representatives for the project. These representatives joined our team and enabled a tight testing loop.
We decided what to defer by considering WillMaker's existing user metrics. We chose to launch in only some US states, rather than all. We identified which states by examining a selection of user and traffic data. We applied the 80/20 Rule. We realized that by focusing on only 10 states we could reach 55% of existing user locations.
Having the roadmap was instrumental at this stage. It helped us visualize our decisions, and communicate when the remaining features would launch. It helped us agree on a timeline that was reflective of the team's velocity and Nolo's business strategy.
We established a "fast follow" process to release the deferred features. These features were organized in order of priority into numbered batches (or versions). We placed fast follow batches into sprints succeeding the launch. This was reflected on the roadmap.
Consumer Portal and a second Hivekind team
As the forms of WillMaker Online were progressing, a looming reality was emerging. Some supporting services had to be built to make WillMaker Online complete. These services went beyond what the Full Online Will had covered. Until this point, they had taken a back seat in our planning.
Chief among these was an application we dubbed the Consumer Portal. This would handle the workflow from landing, through to sign up, payment, and forms access.
WillMaker Online was to be an immersive suite of products. The existing workflow that Nolo had for this for other DIY products wasn't appropriate.
Our team couldn't stay on track with forms work and also build the Consumer Portal. So we brought in a second Hivekind team to help. This second team was to stay on the project until the initial launch. Their objectives were to
- build the Consumer Portal.
- help with its integration with WillMaker Online.
- carry out any other integration or supportive work to assist the launch.
This increase in capacity allowed us to bring Consumer Portal fully onto our roadmap. We could give it a reasonable estimate and timeframe. We remained on track to our target launch date.
WillMaker Online goes live!
Our launch scope was fully understood and planned. We knew what features would come soon after via fast follow. Supporting services were being developed and integrated in parallel. We'd done our planning well. Our engineers continued to work at their steady pace thanks to our sprint cadence.
When our launch date came around we were ready. We had completed the features that were in scope. We used a feature toggle to direct 5% of willmaker.com traffic to the Online experience.
This was a huge win for us, and to mark the occasion we went out to celebrate:
Party time after the launch
The end of the beginning: Product direction after launch
You might think the launch was the end of a significant relationship between us and Nolo. But it was really just the beginning. Even after the fast follows there were many other things Nolo wanted to do with WillMaker Online.
On top of this, Nolo had plans to build other major products on the forms platform. Estate planning is just one service Nolo helps its customers with. We were beginning to look at others. The strategic reasons for creating WillMaker Online were at our fingertips now, and we began making plans to pursue them.
As for the rollout of WillMaker Online: Three months after launch we had expanded to all 50 US states. We were live nationwide. Six months after launch 100% of willmaker.com users were directed to WillMaker Online. By that time Nolo was selling bundles of the product which included either Online only, or Online + Desktop.
--
Working with Nolo was an absolute pleasure. Their team was fantastic and most welcoming of our contribution. If you'd like to try WillMaker Online, you can find it here:
