In the race to launch and beat your competitors to market, it’s easy to put ‘unnecessary’ tasks (like documentation) on the back-burner.
But according to Write the Docs documentarian community, documentation should be both precursory and participatory. This means that you should begin documenting before you begin developing and involve everyone from developers, to product managers, to end users.
We need to get away from the idea of documentation as a box-ticking exercise and move towards one that sees documentation as a vital component of development.
How documentation contributes to Minimum Viable Product
In developing a Minimum Viable Product (MVP), you design and develop the final, complete set of product features only after considering feedback from the product’s initial users. Feedback is paramount.
This process tells you that your product:
- Offers sufficient value for people to use or buy it
- Shows that there’s significant future benefit to keep the attention of early adopters
- Creates a feedback loop that reveals guidance for future development
If all this sounds obvious, getting too excited about including lots of shiny features can get in the way of producing your Minimum Viable Product. In the past, many products have been launched that did not consider feedback from actual potential customers.
Instead of developing blindly, it means you’re building software that your customers actually want, instead of the software you think they should want. Having a product documentation as part of your Minimum Viable Product will help you address this mistake.
Early customer traction
Every SaaS startup wants customers or early prospects, right? Developing an MVP is all about getting customers on board, to test out the product market fit, even before you launch.
Documentation is a great way of getting people to understand the potential of your product without having to build the whole thing.
The whole idea of developing an MVP is to have a core user base of customers or prospects before you go to market. Documentation illustrates the value of your product, even when it doesn’t exist.
MVP means different things to different people, but it always means finding out if users will actually want and use your product. Documentation means you’re putting users at the heart of your product.
Marketing your product early
Acquiring customers or early prospects is, of course, closely related to marketing. Marketing is all about communicating your core vision to the masses.
At this stage, you’ve got to get the users to see the potential of your product. If you start with the Grand Problem then your product will fail. Your Minimum Viable Product is one of the steps that you’re taking towards that final vision.
Documentation is the great explainer on the journey that you need to take your users on when launching a new product.
It underscores what the best SaaS companies know already: you’re not really selling software – you’re selling an idea. You’re solving a problem.
Even when you communicate your overall vision, the MVP you come up with may be far from ideal. That’s okay. All you have to do is get the early adopters on board (and the rest will follow, hopefully).
In MVP stage, you may not even have any software to offer at all. It might just be a landing page containing your value proposition, or a wireframe, or an explainer video. It’s just enough to make potential customers see what you’re offering.
Even if you’re at the software stage, it stands to reason that your product isn’t necessarily as intuitive as it will be later down the line, after extensive development. Some products will be usable straight away – others not so much.
Documentation can help with usability at this stage, even if it becomes redundant later (you can just archive it).
Scale your product
Once your product is usable, it has a few customers, they’re happy… you want to scale your product. But you find you’re hampered by the cost of supporting those customers.
In the Minimum Viable Product phase, you may not have many resources – least of all support staff. You may be lucky enough to be able to afford one dedicated person fielding customer queries, or the emails may be distributed across your team.
Documentation can be a bit of silver bullet in providing support and information for your customers’ most pressing questions, without having to answer loads of emails. It allows you to reach more customers, faster.
Scaling effectively means you can get more done without necessarily investing a lot more resource. Your progress is not hampered by your (lack of) existing infrastructure.
Developing a Minimum Viable Product is not just about being lean and racing to market. It’s about soliciting the feedback that you need from your early users to build a Minimum Marketable Product that is likely to launch successfully.
You can enable comments from your users and use it as a kind of external wiki. This will contribute towards building excitement, and even a community, around your product.
If you document certain potential features, you can ask if your users actually want them. If certain features don’t get much interest, consider removing them.
Looking at your knowledge base analytics will show you the pages that your users are most interested in. You can see what features eventually led users to sign up for a trial or to hear more.
Save more time
Time is all-important in that race to market for your product. Making the most of your time is all about wisely deciding where to distribute it.
If documentation seems like a huge time investment, it’s not nearly as huge as building a whole product and finding out it doesn’t work and people don’t want it.
By wisely investing your time in building a working knowledge base that serves your customers, you’re enabling that feedback loop. You’re saving valuable time that would have been wasted had you not solicited that feedback.
With solutions like Document360 on the market, building your SaaS knowledge base is easier than ever.
Reflect on your product
Documentation forces you to slow down and consider your product. In the delightful haste and chaos of running a SaaS startup, you’ll have the rare opportunity to lay your ideas down on the table and properly assess them.
It’s a way for your whole team to get involved in the product while working towards making it a reality. They can refer back to your documentation again and again, whenever they need it.
It provides a way to make your ideas concrete and reflect on your process. If it doesn’t make sense in the documentation, it likely won’t make sense for your users.
Creating your knowledge base is not necessarily a speedy process, but it vastly increases your chances of launch success – adoption, paying customers, and subscription renewals
Your documentation helps with your MVP in all kinds of ways. Far from being a drain on your resources, it can be a shortcut to scaling, a feedback mechanism, improve your usability and even help you acquire your first customers.
Writing documentation in your journey towards a Minimum Viable Product is different to writing documentation when your software is already launched, with paying users.
You have far less material to draw on in deciding what documentation to produce. You’ll have to go with your gut and iterate as you go along. But this process will bring you closer to your users, and make your product even better.
Building your SaaS knowledge base is easier than ever. Claim your free trial of Document360 right now.
Image by Alvaro Reyes on Unsplash