What are the barely sufficient prerequisites your product needs to satisfy, before it’s successful? Well, it more or less needs to solve your customers’ problems, as it promises. And that should require the minimum possible effort from them. Or as stated in the Agile manifesto: you need to focus on working software over comprehensive documentation.
Actually, Agile with working software over comprehensive documentation focuses on “internal documentation”. This type of documentation may include software specs (written at the beginning), system requirements, use cases; or work-flow diagrams and any type of information produced throughout the software development life-cycle. Documentation is created to support current and future development efforts.
But let’s try to explain why it’s really important to provide your customers with barely sufficient help content or external documentation (looking at it from the development team’s perspective). This type of help content, if well-structured, will not only help you with on-boarding users and customers. It will also be a valuable tool for your development teams as well.
Working software over comprehensive documentation
Once we get into designing and building software, we may forget how it feels to be a customer/user. That’s despite the fact that we, ourselves, are in that position too when using software solutions from third party vendors. And that misunderstanding might also happen when we roll up our sleeves to conjure up our own documentation and, finally, launch our product.
So, how can we strike a balance in both these cases? That is to say, both in software and the documentation that accompanies it. Well, it takes a little empathy, as we need to constantly put ourselves in our customers shoes. Luckily, empathy is a soft skill and can be developed.
First, make it work
That’s a statement that may refer back to any version of your product. Make it work, even if it’s your MVP. An MVP does not mean that the app or the software solution you’re developing should be buggy. A rushed and roughly developed application/software is also a rushed and, more often than not, buggy product in your early adopters’ hands. And that won’t give you the valuable feedback you need for the next steps. Nevertheless, the feedback you’ll get is going to be clear enough: quit or try again.
All of which begs the question: Is a working software enough?
No.
Make it easy to use
By working software, we don’t hope that one way or the other customers will finally find a way to use it. To put a name on the right mindset, let’s focus on the empathy we mentioned above. Let’s suppose that after some tedious, time-consuming search, you finally found the one ‘precious’ app or service you’ve been looking for? Especially if it were the one to solve you a specific problem or offered you a great feature. How would you feel if — a few minutes later — you found out that it’s exceptionally hard to figure out how to make it work? And if you finally did make it work, would you still want to use it? We guess not. Frustration is one of the most prominent deal breakers.
Make it intuitive — Don’t make them think
Make sure you create as many “aha moments” for users, as possible. Meaning, you make them excited on how easy your app/software is to use. Devote some time with your team to make smart decisions on functionality, such as placing a button here, or a shape there, making it easier for people to use it, right when they need it.
Rather, make your app invisible to customers. Make them feel as if — while using your app — they are just solving their problems. Just how a good movie makes you feel when it allows you to invest yourself into the plot. You’re not thinking about the director’s decisions or how performers are acting — unless, perhaps, if you are a professional actor yourself 😉. You can use this mentality as your guide to drive software/app’s development and documentation generation.
So far so good, right? How about the documentation part?
If an app doesn’t work — i.e. is not intuitive (enough) for users to feel comfortable when they use it right from the day one — there is no documentation that would be good enough to make up for that.
Who wants to read instructions?
The answer is simple: No one.
Customers need a solution to their problem, not an extra reading resource. They need to save time and focus on growing and expanding their business (for B2B products). They need to save time to spend on their personal interests (for B2C products). Even if they love reading — we hope they do— they will, without a doubt, choose something else to read, instead 😊.
With that in mind, even if you build your software/app as described above, you should also be mindful when writing your help content.
Produce help content, the right way.
What is the right way? In short, as with your minimum viable (and working) product, you should focus on minimum viable and extendable documentation.
And, mind you, it’s not only about the volume of your documentation. Focusing on “limited” documentation does not guarantee you customer satisfaction for anyone to use your software solution. The quality of your documentation is also important.
Here are some things you need to consider when preparing documentation/help content:
Structure it the right way
Make it easy for your users to find an answer on a burning question, helping them solve a problem. That’s for your Knowledge Base and your FAQs, alike.
Minimize waste
Not only in help content generation, but for anyone reading it, too. Re-usability of content in your documentation promotes efficiency. Keep it Lean. For example, write an article or block of information in a way that might help users in different ways. A single article can be usable within different types of context. Articles should be structured in a way to avoid waste, as in duplicating an article with small changes for different types of context. Try to find out if any of the members of your team seem to be more keen to write these articles, or are eager to take on this. Read the produced content and make sure it doesn’t cause confusion or frustration to users.
Adapt/Update documentation when needed
Documentation can become outdated. And you need to keep adding documents for new features when they come out. Be mindful of how the respective documentation will be added. That, of course, also depends on the team’s consistency and maturity. Different teams need to communicate changes. Is there a process set up to support the flow of feedback?
Make the best out of help content generation
Documentation creates opportunities for feedback exchange between developers and content teams (or people that create content).Conjuring up your product’s first version of a documentation may help you view your product from another perspective, and discover problems (of any kind) that you were not aware of.
Pay extra attention to wording and style
Your writing style may be “deal-closer” when it comes to help content (of any type). Having your customers in mind as you write up your documents will guide you in choosing the right words and the right tone. For example, instead of a title such as “feature x functionality”, try a “How do I use function x to achieve y.
Delegate help content production to the right people
When developing your documentation (and your product, of course) beware of the fact that you (and your team) are biased. A solution to that may be assigning documentation production to someone that has not been that involved in software development provided that there is no content team yet,in a way to minimize biases and increase objectivity.
Our take on it
What is working software over comprehensive documentation for us? If you are a regular reader of our blog, you’ll be in the know that at Starttech we go the lean way. Our Venture Building team makes the best effort to guide our startups in applying Lean and Agile methodologies from day one. By helping startups be in the mindset of “working software over comprehensive documentation”, we help them minimize waste; and radically increase the chances of future success.
Element of trust
Though documentation is not a prerequisite for an MVP launch as we mentioned above, having a barely sufficient documentation in place, is one of our top priorities. And that because it makes it easier for customers to give our solution a try. It helps users feel confident they won’t be wasting their time on a piece of software product that promises and doesn’t deliver. To put it another way, a barely sufficient documentation acts as an element of trust.
Trust is of great importance for customers of a distant market as the one we target. All our portfolio startups are developing B2B SaaS products that are focused exclusively on the US market. And so, it’s essential for us to provide our US users and potential customers all over the world with all the information they might need, right from the beginning.
And starting with fundamental documentation helps us set the ground for the “complete” documentation that we’ll have built in the long run, as our companies grow. Most importantly, we can do this best by implementing any adaptations and additions in conjunction with product development and customers’ feedback (that’s based on metrics) on the initial barely sufficient documentation.
Automation
Another aspect worth mentioning, is our effort to develop automation at all levels that can support it. It’s one that empowers the whys behind the need of having documentation set in place early on. Business viability is largely dependent on the level of automation. Our products — including their respective websites — should make it easy for users to sign up and start using the apps without any help or pre-sales support. And that’s what will make people stay and become regular subscribers.
Robustness
If help is required at any point, we try to make sure that our users will be able to find a helpful Knowledge Base article, with a brief search. And there is, of course, a summarized FAQ section for users that are now in the process of considering our products. All these items are generated at a barely sufficient level. Above all, we try to make sure that all our software products work well, before we release them. And through repetitive development cycles, we try to ensure robustness in functionality throughout the life of our products.
Be customer-oriented
All in all, having your barely sufficient help content in place to support your working software solution you get the chance to pull your potential customers into your sales funnel. So, make sure you set an eye on your customers, early on in business development.
