Your address will show here +12 34 56 78

Part #1: Defining the Product

Define your Product Concept in a form of early Product Documentation: product description/product brief. Facilitate cost planning and conceptualization for MVP or New Product Development.

Understanding Product Definition

What Product Definition is?

It is a concept for a product that answers the question of how it should work and why.

 

In most viable approach it is product concept description and development documentation. It includes product/prototype itself viable details, sketches, product personas, cases of use, edge cases and etc. If you have the experience you can create one using many approaches – design sprint, MVP workshop – are just a few approaches of many.

 

 

How is the Product Definition used?

Usually, product definitions are done for many reasons, but they are definitely essential for:

  • production planning and production execution,
  • scaling / scoping,
  • briefing production team,
  • solving edge case scenarios / weak points,
  • creating product lifecycle plan or roadmaps.

Additionally, product definitions are used for:

  • creating ballpark estimation,
  • creating detailed estimation and costs planning,
  • creating solid investor pitch,
  • drafting business model,
  • other.

Product Definition is a part of Product Documentation, which is created in a form for every stakeholder to understand. Because of that, some Product Definition documents can use different structures and types of language including presentations, key-visuals, mockups, prototypes, backlogs/user stories, customer journey maps and etc.

 

 

Why should you create one?

The main reason for defining the product is creating the concept. The concept is usually easier understood and clearer than an idea and can lead straight to planning development approach and estimations.

 

Good Product Definition in a form of Product Description / Product Brief should be done for:

  • product or service conceptualization,
  • lowering the risk of misconceptions by any stakeholder,
  • finding weak points of an idea,
  • easier and faster kickoff of the project,
  • more precise/realistic and faster estimations.

For new product development, the golden rules are simplicity, focusing on the core value, and quick testing. The lean approach and prototyping are commonly used at this stage.

 

For existing product development, the rules for product definition are to define the core values and opportunities. Usually, in this cases, the concept is already there and is evolving towards providing better services or product versions/iterations.

Principles of good Early Product Documentation

Early Product Documentation vs Product Definition

Early Product Documentation means product description/product brief to showcase the concept, the need and the priorities – specifications.

 

Recipients of such a document will be co-founders, development partners, designers, investors, and any other stakeholders.

 

Early Product Documentation is your first Product Definition. It should include answers to most of the questions regarding the need, the implementation, the context, the edge cases, and etc.

 

 

How to create Product Description / Product Brief?

Write about your product – simple as that, well almost. You should include the most viable information for whoever reading it later. Usually, it should include necessary information about your product described in as simple to understand language as it can be.

 

The number one rule is to create the description in a way which is sufficient to be understood by the specific stakeholder – investor doesn’t necessarily need to know how refunding policies work in online stores, however, a developer should know about it to suggest best payment refunding mechanisms or even create a custom one for you if necessary. Because of that description for the development is usually more detailed than for an investor.

 

For products that are using specific domain knowledge, you should write the description in a way that a technical partner (or investor) that don’t understand it yet* will still be able to have a clear vision of what problem does it solve.

 

HINT: Keep it simple and explicit in the main part.

 

 

Fewer ideas more concepts.

The Product Definition documents shouldn’t be your mind map for ideas, it should already provide a draft of a concept. It can then evolve, but it should evolve from a solid form – which a concept is, rather something ethereal like an idea.

 

The gradation is like as follows:

  1. Thoughts, experiences, challenges, and some random associations should lead to generating ideas.
  2. Ideas are more abstract entities and usually for many degrees an imagined representation of solutions, objects, interactions and etc – they are not very solid as they are emerging from a nonentity or very abstract dimensions.
  3. If ideas should lead to creating real solutions then the conceptualization phase should be done over an idea. Conceptualisation in the most simple words is challenging an idea with real-life examples and use cases. This part is quite challenging if you don’t have too much data or when you are a wishful thinker. The best approach here is to be still very simple, and honest with the real case scenarios. For this part one of the methods that are used by young entrepreneurs is business canvas – however, the flaw of this method is that a product or a service itself is just a part of a greater puzzle.
  4. The concept is a solid model of an idea, that is better represented by real case scenarios and can be physically tested in real life. It includes examples of use, critical value definition, limitations, clear definitions, exceptions, edge case scenarios, and logic definitions. It can be complex or simple. In the early stage startups it should always be oversimplified rather than overcomplex – yes, the reality is not trivial, but complexity costs a lot of production money, and concepts never guarantee success.
    Another thing to keep concepts simple is to make them more flexible to changes. The only one challenge here would be to find the definition of a solid core of it to scale up from.

 

Avoid Wishlist.

Wishlists come from complex ideas and create overcomplicated concepts. It is against the simplicity rule.

 

Wishlists are not overly so bad, to not to use them at all, but the biggest flaw of them is that every element in the W-L is having almost the same priority as all the other elements – this creates confusion and complexity which raises price and budget demands, or compromises quality in product development.

 

To find the most important elements to be included in the product definition, project managers usually use MoSCoW method – which is a very good method to use in conceptualization stage, and in project management/product owning role. This is a very good method to define the service/product goals or critical value that Must be delivered in the very first step of the development.

 

MoSCoW: Must-o-ShouldCould-o-Would haves. I will emphasize it more in the future, but in the meantime check out this link: MoSCoW Wikipedia.

 

HINT: It is better to use W-L in a way that software development calls icebox – you put there your idea, and you froze it for later, so whenever the time comes you can verify if it is still fresh and needed, or be thrown away.

Simple vs Detailed Early Product Documentation

You can create variations of versions of your product description/product brief, however, the most common approached looking for a development is the simple and detailed type of the Product Definition.

 

The simple one is for quick feedback, RFP costs saving, ballpark estimations, and vendors early filtering. Still, the detailed product definition should be done after this, however, if done properly it will save a lot of time, can give quality feedback and make the next steps much easier and cheaper.

 

The detailed one is for profound feedback, precise estimation if necessary, development approach planning, prototyping, production team briefing, product roadmap creation, drafting business model, and etc. If this part is done properly the money invested at this stage can save a lot of budget in the production phase and will make investors pitching easier.

 

 

Simple / Minimum version of Product Document / Product Brief

GOOD FOR:

  • early and shorter Request for Proposal stage (RFP),
  • ballpark estimation to figure out the range of the budget needed,
  • early feedback about the concept, and the product definition itself,
  • unexperienced product owners or founders as it is easy to create,
  • saving time – a short time of preparation (from one day to one week),
  • saving money – can be done by the founder or a product owner.

BAD FOR:

  • product development roadmap – it is just too simple and to early to have that,
  • precise and realistic estimation – you will get only a range of numbers and they can vary from very low to sky high, it won’t be realistic but ballpark,
  • finding strong and weak points – as simple product definition is still a vague description of the concept, it is difficult to find those.

 

Detailed version of Product Document / Product Brief

Good For:

  • challenging the concept itself,
  • precise estimation,
  • profound feedback and development approach plan,
  • Must, Should, Could, Would haves – scalability plan,
  • realistic offers from development partners,
  • finding the best tech stack,
  • creating simple prototypes and drafting business model,
  • saving budget on misconception mistakes,
  • creating better pitch decks as you will address most of the difficult questions already.

Bad For:

  • founders not necessary clear with their concept – as the process of creating the detailed product definition is time-consuming 3-6 weeks or longer in some cases,
  • founders that have limited time to participate in product workshop.

How to create simple product description / product brief?

Who prepares it?

Should be prepared by:

  • founder,
  • product/business analyst.

 

Must haves to include

#1 Description

  • Brief Description, 1-3 paragraphs to describe the most important aspects of the product – general concept,
  • Answer the Question: Why do you want to create the solution?
  • Personas that will be using it:- role [guest, buyer, contributor, publisher, doctor, athlete, property owner, admin, etc.],- interest in using the solution / what problem of a user must, should, or could be solved (explicitly use those word from MoSCoW),- users background: occupation, age, gender – if necessary.
  • Accessibility / Mobility – how and in what circumstances the solution should be used?

 

#2 Mockups or Key-Visual

Mockup or Key-Visual should show the most important aspect or aspects of the solution. It can be application screen, gear sketch, use of gear sketch and etc. It can be hand-drawn.

 

#3 Simple user flow

Step by step guide on critical steps of using the solution – it should be simple and focused on the most important aspects.

 

For very simple example: login -> check your account balance -> send a question to an admin.

 

Another more advanced example would be: turn the panic button application in your mobile -> put on alarm bracelet -> shake wrist for 5 seconds -> send a message to friends FB messenger about your position and alarm indicator.

How to create detailed product description / product brief?

Who prepares it?

Should be prepared by:

  • team at least composed with founder + product/business analyst + technical support/developer/ technical project manager.

 

Must haves to include

#1 Description

  • The description that explains the product concept, how it will be used, what for it will be used, when and etc.
  • Draft for monetization if necessary to be included.
  • Why do founders want to create this system, their expertise, and how they will be involved in the business?
  • Personas that will be using it:- role [guest, buyer, contributor, publisher, doctor, athlete, property owner, admin, etc.],- interest in using the solution / what problem of a user must, should, or could be solved (explicitly use those word from MoSCoW),- users background: occupation, age, gender – if necessary.
  • Accessibility / Mobility – how and in what circumstances the solution should be used?
  • UX/UI guidelines.
  • (optional) References to similar products with description.

 

#2 Mockups / Wireframes

It should include either screen-by-screen wire-frames or hi-fidelity mockups for main screens. It should be as complete as it can be.

 

Mockups, however, should be done for the main used device / interface (mobile/desktop, etc.) to already give feedback about the main use of the product.

 

#3 User Flows / Diagrams

Guide to overview how the personas will be engaged by the system. It can show user flows, system modules, interactions.

 

It can be presented in a form of a graph which is usually easier and clearer to understand than a text. Text should be used to explain some critical parts or interactions or edge cases.

 

#4 User Stories / Sample Backlog

User stories or backlog elements are usually done for the development team to understand. During the workshop, it can be created by anyone. However, for the development, it still will be refined and reviewed by the Project Manager and Product Owner for better Quality Standards and Good Practices.

 

On the level of early product documentation it is usually created as a sample:

 

Description.
As a User I want to be able to login to the platform from every subpage of the system. I would like to see the button for the login in clearly and all the time.

Definition of Done.
On every page, login CTA/Button is visible and clickable. After clicking the CTA/Button user is redirected to login page.

 

Those should be written for all the personas and actions that will happen. Sometimes a persona named system can be described here anytime when something should work autonomously by the product itself.

 

The complementary elements to the above are mockups.

Sign up for the upcoming update!

We will send you information about updates of this part of the handbook and on upcoming next parts.