Author: Ivan Topolya

How to create a product vision?

Product vision is formed at the beginning of the product journey to identify clients and verify their motivations, determine product’s identity, and guide the product team in its product management endeavor. It is a product owner’s responsibility to own, create, and maintain product vision. However, product vision is not authored solely by the product owner and is to be heavily influenced by major groups of product stakeholders (clients (ultimate clients, clients of clients), users, product team, other stakeholders).

Product vision provides a vivid picture of how a product aims to deliver value to the clients by prioritizing and addressing their key motivations, describes reasons for creating the product, and covers core product’s benefits and features. It develops a long-term outlook on the product’s ultimate state to be reached and thus is a starting point for developing a product roadmap (product strategy).

To fulfill its communication and guidance functions for different audiences product vision might be prepared at various levels of depth / detail, e.g. a lighter version for executive attention, a regular version to communicate with clients and users, and a deep, extended version to be used by the product team on a daily basis.

Thus, a product vision is a product’s strategic ideal. Product visioning is performed in accordance with SPACE protocol.

Purpose of the product vision: to evaluate and decide whether a right product is to be developed and delivered. This evaluation comes from assessing product’s expected value:

  • the product team correctly identified the clients and their problems, needs, and motivations
  • the proposed product addresses client’s needs
  • the proposed product provides the clients with meaningful benefits

Extra functions of the product vision: product vision also helps the product team to:

  • visualize future (literally)
  • convey purpose and motivate product team
  • filter and prioritize change initiatives
  • provide focused direction while avoiding product drift

Qualities of a product vision: for the product vision to be valuable for the team as the key guiding principle it should be:

  • reasoned – focused on clients’ needs, addressing clients’ problems
  • big – long-term, ambitious, linked to company’s vision and strategy
  • complete – comprehensive, focused, relevant, meaningful
  • specific – concise, short, clear, easily communicated
  • powerful – emotional, engaging, aspirational, motivational
  • deliverable – achievable, actionable, measurable, adaptive

Vision statement formula: to make vision statement short and clear one of the following templates can be used:

  • For a <client/user>, who has <certain problems, needs, or other motivations>, a <product> is a <product type> that provides <benefits> while <other competitive products> fail at <description of product’s superiority>.  
  • For a <client/user>, a <product> is a <product type> that provides <benefits> by addressing <client’s certain problems, needs, or other motivations>, and outperforms <other competitive products> by <description of product’s superiority>.  

Areas covered by the product vision: to produce an appealing and thorough product vision following product-related areas would be covered:   

  • clients, users and other key stakeholders – What are the target markets, clients, and users of the product? Who are other stakeholders of the product? Who is the ultimate client? Who are the clients of the product team’s clients?
  • client area of struggle – What fields of activities of the client require attention and provide an opportunity for improvement and change with the help of the product?
  • clients’ problems, needs and other motivations – What are the ultimate client’s (or clients of the product team’s clients’) motivations, needs and objectives? How do they see, approach, and employ the direct clients of the product? What do they expect of them? What are the clients’ primary objectives which drive their motivation for change? What is blocking the client now from achieving these objectives? What problems and issues can the product address and what needs can it satisfy?
  • benefits of the product – What benefits will the product bring to address clients’ motivations? What are the key functions and features of the product?
  • value proposition – What is the vision statement of the product? How would the product create value for the clients? What feelings would clients’ experience in the course of owning, using, and associating with it?
  • timing – When does the client need the product? How long will the client use the product? What are expected changes in the environment that might affect the client and hence, his expectations from the product and the way the client would use it? What are the major stages of product lifecycle and expected rollout milestones? How long the product will be supported?
  • product performance – What are measures of product’s success? How do we define product goals and identify key value indicators to measure them?
  • (extra) alignment – How the product fits with overall corporate vision and strategy? What are the benefits of the product for the company?
  • (extra) competition – How does the product perform against and differentiates itself from one the client is using now and other market products? What are the current strengths and weaknesses of the product? What are the coming opportunities and threats to the product?
  • (extra) channels – How will the clients get access to the product? Is the product positioned for specific channels or will be universally accessible?
  • (extra) price – What is the price the clients are willing, aiming, and able to pay for the product? What price structure would be offered? What are the key drivers of the price upon accessing and while using the price? How does the pricing of the product compare to that of competitors’ offerings?

What needs to be done: product vision creation follows a design thinking approach built around product vision questionnaire above:

  • general recommendations – focus on the client, look beyond the product, develop iteratively and incrementally, establish and support teamwork, lead and let for the creative flow, build consensus, write everything down
  • tuning in – identify your clients and users, approach them, see them, talk and listen to them
  • scoping – identify the topic to address (e.g. client’s problems and why they are worth solving, current solutions and why they fail), structure approaches to researching and exploring the topic (e.g. product vision questionnaire), define the expected results of topic exploration
  • ideating – propose ideas on the topic addressed (e.g. create a motivation (problem) statement, define key product properties (pillars) that address motivations (problems), assign ultimate values to those properties (pillars)), filter, prioritize and sort out proposed ideas
  • formulating – decompose and distill proposed ideas, find patterns, group around similar themes, synthesize a final topic result (e.g. a proposed product’s vision statement, set higher-level objectives to achieve product vision statement), assemble and review the product vision draft
  • completing – share and validate the product vision with clients, users and other stakeholders, update product vision upon consultations, finalize the product vision
  • moving on – start developing a product roadmap!

Tools that can be used:

  • Product vision canvas
  • Product vision board
  • Product vision box

How to run a meeting?

Meetings are designed and assembled to involve and connect people for things to happen (e.g. keep the projects moving, achieve consensus on the issues, make decisions). Meetings generally assume some form of communication (gathering, disseminating, or exchanging information), but foremost to achieve a meaningful result (produce opinions, ideas, or decisions). Preparing for and conducting meeting depends on the topics covered, number of participants (one-on-one, team event, all-hands), context (e.g. (de)brief, planning, problem-solving, negotiations), and expected results (as above).

Purpose of the meeting: to act upon the results of the meeting. Results of the meeting can take form of:

  • decisions made
  • conclusive discussions held
  • aligned understanding
  • communication shortcut aiming to compensate for weaknesses of other communication means where benefits of holding a meeting outweigh its costs (e.g. a quick recap for the project members in order to synchronize efforts in a highly dynamic environment)

Expected results of the meeting:  

  • expected results of the decisions made during the meeting are achieved
  • actions are taken upon decisions made during the meeting
  • meeting decisions are communicated
  • decisions made during the meeting are documented and agreed upon
  • decisions are made

What needs to be done:

  • preparing the meeting outcomes – identify the purpose and expected outcomes of the meeting, assess whether meeting is necessary at all or other ways of achieving the meeting objective are appropriate, identify the type of the meeting (decision making, informational, creative), prepare a draft meeting memo, prepare a meeting scenario, define meeting roles (opening, leading, facilitating, notes taking, supporting with expertise, handling administrative and technical issues)
  • proposing the meeting agenda – prepare meeting agenda while keeping it light, align meeting agenda with meeting purpose and objectives, assign time blocks to each topic, align meeting length with proposed agenda items, set a meeting timetable while allowing for slack (at the start, during the meeting), prepare information for the meeting
  • emulating the meeting –  model expected outcomes, model possible participants behavior, map participants’ attitudes towards the meeting agenda items
  • identifying and engaging participants – identify appropriate participants, limit the number of participants, identify critical and possible participants, assess whether participants have appropriate authority and competence to participate, act, and add value to the meeting, schedule the meeting, send invitations for the meeting and disseminate meeting agenda, collect participants’ opinions on agenda, inquire for top key stakeholders participation, confirm participants presence, ask participants to come prepared and allow participants to prepare for the meeting, prewire the discussion, resolve issues before the actual meeting
  • preparing for the meeting – book a place in advance, resolve technical issues, exclude distractors, make meeting environment comfortable
  • leading the meeting – find a strong leader for the meeting, delegate meeting leadership or take charge for the meeting, set the tone for the meeting, model and moderate appropriate behavior
  • opening the meeting – start on time, thank for participating in the beginning, articulate meeting goals and expected outcomes, rehearse meeting purpose and objectives with participants, set the rules of meeting conduct, start with last meeting recap
  • going through the meeting – control flow of the meeting, stick with the agenda, affirm the progress, don’t get bothered in insignificant detail or off-topic items, capture the points of the meeting (decisions, assignments, discussions, topics for further research and action), look out for and eliminate distractors, seek for both ideas and critical analysis, exclude unrelated topics to other events or venues of communication, keep meetings short
  • conducting the meeting – manage the participants involvement, encourage participation and seek ways to increase involvement of the participants, let others speak, balance dominators, involve quiets, acknowledge, reflect back, validate opinions, make feel understood, interrupt, push the decision, hurry the decision, defer discussion, assign or delegate discussion
  • decision making – bring out the decision in the proposed by the meeting rules manner (voting, unilaterally)
  • closing the meeting – collect final thoughts, make conclusions, perform debrief, sum up results and performance of the meeting, identify areas for improvement
  • finishing the meeting – end on time or before scheduled end, recap at the meeting end with preliminary meeting memo, thank for participating in the end
  • documenting decisions – capture what needs to be done in the meeting memo: decisions, key points addressed, topics and issues for further research, means of control
  • communication of decisions – disseminate the meeting memo, obtain participants confirmations or adjustments to meeting memo, prepare final version of meeting memo
  • controlling execution of decisions – follow-up on issues addressed in the memo, request for confirmation of actions taken and assignments completed
  • moving on – proceed to other items on your strategic agenda

Tools to be used:

  • agenda
  • meeting memo (draft and final)

 

How to run a sprint retrospective?

 

Sprint retrospective is performed at the end of the sprint to decide and act on the practices and protocol followed by the Product team. Sprint retrospectives are performed in accordance with SPACE protocol.

Purpose of the retrospective: to evaluate and decide whether a product is being delivered right. This evaluation comes from assessing practices and protocol value and usefulness:

  • practices and protocol focus on the needs / backlog items that were included with the sprint
  • practices and protocol stimulate achieving sprint goals on time
  • practices and protocol are convenient and efficient to follow

Expected results of the retrospective:

  • collective wisdom is updated and enhanced – practices and protocol are updated, black book is rehearsed, framework principles and values are acknowledged
  • decision to adjust practices and protocol is made – product team confirms altering the way it is managed and operates in its entirety or partially
  • possible adjustments to practices and protocol are identified and formulated – feedback items are grouped, structured, and analyzed as practice and protocol modifications
  • team feedback is collected – opinions of the team members on the practices and protocol are gathered
  • full sprint recap is performed – recap assumes presenting all sprint outcomes, performance metrics, successes, issues, failures, and disasters, no exclusions or omissions are made

Areas to be covered by the retrospective: to perform a thorough research and reflection on team performance and to provide a focused improvement following areas would be covered:

  • key outtakes – Did we reach sprint goals? What did we learn? What key conclusions did we make? How do we evaluate our interaction with clients and partners?
  • sprint results – Were the sprint tasks achieved? What was achieved at the task level? What metrics demonstrate task achievement? How do we evaluate results over task – success, issue, failure, or disaster?
  • black book – What were our biggest misses? What were the reasons and what we didn’t expect or account for? How can we prevent another occurrence of the same or a similar issue? What could become a disaster in the coming sprints? What should be considered in the plans, protocol, approaches in dealing with clients and partners?
  • specific results – What has been done good or perfect? What hasn’t been done and why? What were the reasons and what we didn’t expect or account for? What was being done above the sprint scope? What tasks were cancelled or dropped during the sprint and why? What should be done in future to adjust for that?
  • protocol – What worked in the proposed approach – and has to be kept and strengthened? What didn’t work in the proposed approach – and has to be improved, adjusted, or dropped?

What needs to be done:

  • recap planning – gather data on sprint outcomes, performance metrics, consider if sprint goal was achieved, identify successes, issues, failures, and disasters, make the discussion script, understand team members’ availability, book the place, resolve technical issues, prepare FAQs not covered in the scenario / script, decide on the way to address question during the recap, identify areas and questions for team members’ feedback
  • recap running – perform recap
  • collecting feedback – gather team members’ feedback on the matters relevant and identified by the product team
  • identifying and formulating adjustments to practices and protocol – transform feedback to potentially actionable items of practices and protocol
  • documenting decisions – capture what needs to be done: decisions regarding adjustments to practices and protocol
  • moving on – let go!

Tools to be used:

  • closing memo
  • black book

How to run a sprint review / demo?

Sprint review is performed at the end of the sprint to decide and act on the product (or its increment) developed by the Product team. Sprint reviews are performed in accordance with SPACE protocol.

Purpose of the review: to evaluate and decide whether a right product is being delivered. This evaluation comes from assessing product’s value and usefulness:

  • the product addresses needs / backlog items that were included with the sprint
  • the product performs its functions as expected / in the right manner
  • the product is convenient and nice to use

Expected results of the review:

  • launch initiated
  • decision to launch is made – users and the product team confirm shipment of the product in its entirety or partially
  • product (increment) is accepted by the user – user acceptance tests have been performed and they confirm value and performance of the product in its entirety or partially
  • potential additions to the product backlog are identified and collected – feedback items are grouped, structured, and analyzed as future backlog items, however they are not added as such unless they pass through the requirement capture phase
  • user feedback is collected – opinions of the users on the product demonstrated and / or the process of demo are gathered
  • full product (increment) demo is performed – demo assumes presenting all developed during the sprint and expected to launch items, no exclusions or omissions are made

What needs to be done:

  • demo planning – prepare the example, make the script, distribute demo roles, dry run the demo, understand users’ availability, book the place, resolve technical issues, prepare FAQs not covered in the scenario / script, decide on the way to address question during the demo, identify areas and questions for users’ feedback
  • demo running – performing demo
  • collecting feedback – gather users’ feedback on the matters both relevant to the users and identified by the product team
  • identifying potential additions to product backlog – transform feedback to potentially actionable items of the backlog
  • documenting decisions – capture what needs to be done: decisions regarding scope and results of user acceptance and launch of the product
  • launching the product – go live!

Tools to be used:

  • review memo