You built a killer product, yay!
Now make sure it doesn’t die.
I love building products that are well-designed to meet a really important need. I hate. hate. hate. building products that don’t thrive.
My team is very good at building products that are designed to meet a particular user need, in large part because we care about getting it right. By “right,” I mean —
- The right product,
- For the right user,
- That solves the right problem,
- In the right way.
But here’s a secret:
That perfect product is constantly on the precipice of death. It is ready for you to neglect it in one of several common ways so that it can live out the rest of its life as a zombie project — one that exists-ish, but no one is using it, no traffic is being driven to it, no content is being updated or added, and is broken due to browser updates and a lack of maintenance.
Pity the poor app :(
You may have heard the phrase “software is never done.” It’s a dumb phrase, particularly outside the SaaS context. Software can be “done” in the sense that you have a product out that is delivering value. But even if it’s done, it still needs to be maintained. People still need to learn that it exists. People need to be able to use it without breaking. Once those things no longer happen, your done product be dead.
How do we avoid such untimely and devastating deaths? A sustainability plan can definitely help.
What’s in a Sustainability Plan?
In offering this rundown of sustainability planning, I’m making a few assumptions about you, the reader:
- You’re building a product that is not the core mission of your business (ie, you’re not a tech company); and
- You’re building a product that is not designed to create a robust new revenue stream.
For our clients that have engaged us to build a product that is going to substantially impact their business, make them money, or is otherwise core to the organization’s goals, sustainability is more naturally a focus with motivation to sustain baked in.
For the rest of you, here is what you need to consider well before your team writes a line of code (and indeed, best to consider before you even write that grant application, seek funding from leadership, or write an RFP).
You cannot expect to be done paying developers after a public launch of your product. Unless you’re actively testing and iterating, though, it’s going to be substantially less than what you’re paying for active build. Your budget for basic maintenance just cannot be $0 (which is often a reality for grant-funded projects). At an absolute minimum, you should have someone doing a run through the application once a month to check for bugs that might have cropped up due to browser changes, reviewing documentation on technologies underlying the product to be alert for security patches, etc. Extra points for you if you include budget for continued chipping away at your backlog.
Your app may be super awesome, but it matters little if no one learns about it. From the very beginning, you need to budget for ongoing marketing. You cannot rely on PR you may receive after the launch of the product to propel users to your site. Chances are, the users you’re targeting will not ever see those articles. If your organization doesn’t have internal marketing that knows how to market digital products, engage an outside marketing team, and do it early. This is important so that you get a sense of an ongoing budget for marketing post-launch, which can be substantial.
There are very few applications in the legal realm without an important content component. I’m using content quite broadly here to refer to any blog-style articles about a legal issue, information in a product about legal rights and obligations, forms, question flow content, etc.
No matter if you are a non-profit or a massive law firm, the content is used to educate users, promote some action, etc. And if that content is old or… wrong… the product can end up doing more harm than good. At best, it can harm the perceived trustworthiness of your application and/or organization, at worst it can actually cause legal harm to your users.
Content for products we build is often created by people who have other very demanding day jobs. In the law firm context, associates are usually roped into creating content. In the non-profit world, volunteer lawyers or organization staff are brought in to create content. This method is possibly sustainable through the development and launch of a product, but long-term content needs to be someone’s job. Or at least a well-defined part of someone’s job. This obviously comes with cost.
More than one Champion
Often, to get a project through an organization, there is one person who is committed and dedicated to the success of a project. There is benefit in having an internal “product owner” who makes the project their priority, but it sets up the possibility for a challenging situation. What if that person leaves the organization? What if, after launch, they get pulled back into other duties? We see this as a common cause for products fizzling out. Products need more than one champion.
None of this work is worthwhile if you don’t plan for long-term sustainability. We’ve seen way too many good products go to waste due to a lack of planning.
I know a lot of people that read this are invested in the use of technology to improve the way people experience the law. There’s a lot of good work going on out there, let’s work harder to be sure that that work is having the impact we all desire.