What is the best way to document/describe a completely new product?

Question

Describing a new feature, optimization, or new section of an existing app for engineering and the product team is fairly solvable. You can build on a specific existing point of reference and user research to describe the new thing to the teams.

But how do you communicate something big, new, and unfamiliar? You can do market and user research, competitive analysis, draw up real or imagined user journeys, and use all that to describe job stories and scenarios. But this thing starts to get really big (and very un-Agile). To the point that your documents are unlikely to be studied well. But all of that information is no less necessary to getting to MVP.

I'm feeling this more than usual at the moment as I work on a niche product that solves new and unique problems. Some problems that the target industry doesn't even recognize yet. There isn't a lot to point to as reference.

Have you found a consistent and cohesive format to describe a large new MVP in such a way that Engineering can confidently begin planning their stack and iterations?

Or does this "document" need to evolve in chunks over time, with the knowledge that it won't be done until the product is?

Answer 1

You've answered your own question- it's going to evolve over time. The more you document and explore/ use different ways and tools to illustrate and describe the product/ features. Analogies are always good to use to explain products/ features.

Answer 2

But how do you communicate something big, new, and unfamiliar? You can do market and user research, competitive analysis, draw up real or imagined user journeys, and use all that to describe job stories and scenarios.

That is probably true, but you certainly have done some of that, haven't you? Surely, you have some idea of how the new functionality will be used and in what situations it will be helpful.

But this thing starts to get really big (and very un-Agile). To the point that your documents are unlikely to be studied well.

Whether this is the case depends a lot on how far you go in your descriptions:

• Do you describe the problem or also the solution?
• Do you describe how it can be used or do you describe how it works?
• Do you just give an overview, or do you go into detail?

Actually, from your question, I was not entirely sure about the target audience of your documentation. Make sure you distinguish here - a brief introduction might be the same, but end users in the target industry will want to know about different details than developers in the product team.

I'm feeling this more than usual at the moment as I work on a niche product that solves new and unique problems. Some problems that the target industry doesn't even recognize yet.

They don't, but you do. Your documentation needs to convey these problems and embed them into the more general context that people from the target industry already know about.