This page is part of Product Principles

Vision and Mission

  • A good product vision keeps us focused on the customer.
  • A good product vision serves as the North Star for the product organization so that we have a common understanding of what we are hoping to accomplish together.
  • A good product vision inspires ordinary people to create extraordinary products.
  • A good product vision shows us why this work is meaningful. A list of features on a roadmap is not meaningful. How you can positively impact the lives of users and customers is meaningful.
  • A good product vision illustrates how we plan to leverage relevant industry trends and technologies that we believe can help us solve problems for our customers in ways that are just now possible.
  • A good product vision provides the engineering organization with enough clarity about what’s coming in the next several years so they can ensure they have in place an architecture that can serve the need.
  • The product vision is a primary driver of the team topology.
  • The product vision, combined with the annual company objectives, drives the product strategy.
  • A strong product vision serves as one of our most powerful recruiting tools for strong product people.
  • …

From Product Vision vs. Mission

To better understand abstract concepts, I like to explore concrete examples.

Let’s look into “Apple” as an example:

  • Their vision statement is:

    “To make the best products on earth and to leave the world better than we found it.”

  • Their mission statement is:

    “To bring the best user experience to customers through innovative hardware, software, and services.”

If we try to generalize:

  • Vision statement: “{your dream/why?/the change or difference you want to make}”

  • Mission statement: “{your action/what?} through {action vector/scope/how?}”

Read more

Domain Strategic Classification

Having a strong product strategy, vision, and mission is important, but sometimes one may find working on tasks or problems that seem disconnected from delivering value to the end user. In these situations, focus can become unclear. Thinking in terms of domain strategic classification can help you regain clarity and navigate these challenges more effectively.

How important is this context to the success of the organisation?

  • Core domain. It makes an organization unique and different from others. An organization cannot succeed (or even exist) without being exceptionally good in its core domain. Because the core domain is so important, it should receive the highest priority, the biggest effort, and the best developers. You may only identify a single core domain for smaller domains, while larger domains may have more than one. You should be prepared to implement the features of the core domain from scratch.

  • Supporting domain. It is a subdomain that is necessary for the organization to succeed, but it does not fall into the core domain category. It is not generic either because it still requires some level of specialization for the organization in question. You may be able to start with an existing solution and tweak it or extend it to your specific needs.

  • Generic subdomain. It is a subdomain that does not contain anything special to the organization but is still needed for the overall solution to work. You can save a lot of time and work by trying to use off-the-shelf software for your generic subdomains. A typical example would be user identity management.

What role does the context play in the business model?

  • Revenue generator. People pay directly for this.

  • Engagement creator. Users like it but they don’t pay for it.

  • Compliance enforcer. Protects your business reputation and existence.

  • Cost reduction. Saving the costs currently or long-term investment (i.e. internal tools).

From The Bounded Context Canvas and DDD Part 1: Strategic Domain-Driven Design.

Case Study

Writing a case study can help clarify your focus further and highlight any gaps in your understanding. While case studies are often written after a project has been completed, they can also be created at the beginning or during the project to better grasp the overall direction and set expectations for the rest of the process.

A typical case study structure includes the following:

Introduction

  • Describe the situation at the begining
  • Maybe some history - how the one arrived to that situation
  • Define problem, make it measurable (if possible)
  • When solved, what would be unlocked? Potential next steps? Vision?

Project Overview

  • Project phases
  • Ways of working / working model - how does BAU look like?
  • Team composition, size, ramp-up/ramp-down strategy

Challenges and Solutions

  • List of challenges and their respective solutions
  • Not limited to technical challenges - cultural, process/teamwork, product/focus challenges also welcome (refer to Product Principles to get ideas)

Results

  • What is the difference now comparing to the “Introduction” part?
  • Describe the current situation
  • What are measurable improvements? (refer to initial problem)
  • Have we unlocked the next steps? What are next steps now?

Conclusion

  • What can be learnt from this case study, this project, in general?