Product Feature Documentation keeps everyone in the team on the same page, so I decided to write product documentation the way a BA would do it !

This is part of my personal startup-challenge to wear the hats of individual roles of a company in a day #onedaystartuprole . I founded my first company and launching a product Invaana with the all passion and dreams like any other entrepreneur. Then I was thinking about what if I hire people, and when they join the company, how would I make sure the new bees know what exactly I mean by product and what all it should do. So I decided the document the product, which I’ve never done before. So decided to behave like a Business Analyst(BA) for a day and write the product documentation ie., I should not Code(which I love so much) or do other marketing related stuff apart from being business analyst.

So, like any other internet enthusiast, I’ve started googling and reading few blogs. The best thing about being BA he should know everything to the minute fundamentals levels. The image below shows the precision level a BA tries to understand the scenarios. The more the questions BA ask himself or the Founders/team, the more he can create a good product use cases and stories.

So what is user story and a use case ?

User story is a small description of something a user/actor wants to do to accomplish something. For Example: I want to login to change my password . User Stories are written from a single actor perspective with an action and a purpose. Let’s see the above example: I(Actor) want to login(action) to change my password(purpose).

Use case is a description of a set of interactions between a system and one or more actors. They are usually created as documents, and generally include this kind of information like use case title, rationale/description/ goal, actor/user, preconditions, standard paths or extensions, post conditions. Use case focusses more on the path of the interaction.

To conclude, according to me, user stories focus on the action and result, but use cases focus more on the path of achieving an action and how system responds to the actor(ie., interaction between actor and system).

Honestly, I’m not sure If I’m on write track in writing this documentation, but this is much better than having nothing in my hand to show to future employees

Being a Django developer, I strongly advocate KISS principle — Keep It Simple Stupid

So, I tried to make the documentation as light as possible so that future developers need not spends hours of time on reading to understand the product. The documentation simply shoes the basic info — actor, the action and the final result.

Last modified on 2016-11-05