Early in the modest tweetstorm caused by last Friday’s post, I saw this tweet by @JEGrant3:
Here's the power of an #MVP: @avvo just got @KonciseD to consult on improving their product. For free. #leanstartup https://t.co/FNf4BrOzvA
— John E. Grant (@JEGrant3) April 8, 2016
I was mystified. “MVP”? WTF?
But @anseljh came to the rescue, explaining that “MVP” stands for “minimum viable product.” It’s a concept featured in the business methodology known as “lean startup.” This from Wikipedia:
A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent.
So John’s notion—although he mentioned to me that he was to some extent playing devil’s advocate—is that it was legitimate for Avvo to lauch Avvo Legal Forms with rudimentary product. Why delay launch by striving for something more comprehensive, particularly as users can be counted on to offer feedback? If busybodies like me chime in, so much the better!
This idea has since been bandied about on Twitter, with people chiming in for and against. I’m an utter stranger to lean startup, but for several reasons Avvo Legal Forms doesn’t seem to qualify as an example of MVP:
First, there’s nothing to suggest that Avvo regards the templates in Avvo Legal Forms as works in progress.
Second, the issue with Avvo Legal Forms isn’t whether the idea of legal forms is viable, or what features to add. Instead, it’s a matter of quality control, and what’s in order is a fresh start.
Third, you can expect users to point out mistakes and other shortcomings in a template, with the level of input depending on how sophisticated the users are. But Avvo Legal Forms is intended for consumers—it would be rash to expect them to drive post-launch development of Avvo’s templates.
Fourth, even if Avvo had intended to finalize Avvo Legal Forms after launch, they couldn’t have predicted that I’d show up on the scene. So it would be outlandish to imagine my input forming part of planned product development.
And fifth, I offered comments on only one template. And I only scratched the surface of substance and had essentially nothing specific to say about the language used. You can’t go far with that.
So discussing MVP has made for interesting tweeting, but I suggest that it doesn’t actually have any bearing on my comments about Avvo Legal Forms.
A variant on MVP might be a company’s launching a product with some bugs, with the idea that further delay would be more costly than customer griping. There’s nothing to suggest that that’s what happened with Avvo Legal Forms, and intentionally inflicting suboptimal legal forms on consumers wouldn’t be a good idea.
1 thought on “Revisiting Avvo Legal Forms, Part 2: “Minimum Viable Product” and Contract Forms”
As a lawyer who practices in-house at a tech company where we talk frequently about MVPs, I think the concept of an MVP works especially well with contract drafting and offerings like Avvo’s.
But in all this talk about MVPs, it’s critical to understand that a crucial step in creating an MVP is to define what viable means. I would suggest that the minimum viable product for a contract-drafter is a contract that attempts to be compliant with the MSCD or with some other rational contract drafting guidance (if you can find/create an alternative).
Simply saying that we’ll get something (anything!) out there and then iterate on it is not lean development. A careful definition of the minimum viable product, with a thorough but admittedly incomplete idea of what the final product might end up looking like, is an essential part of the lean methodology.
What we’re doing in the lean methodology is testing hypotheses. But the best hypotheses aren’t just wild guesses that we throw against the wall in the hopes that they’ll stick. The best hypotheses–the ones we should strive to employ in an MVP–are (1) based on an accurate understanding of the problem to be solved, (2) testable, and (3) capable of being iterated on.