In the past few years, I have been engaging with more and more technology organizations that started as pure service providers and are now evolving to offer their own products on the marketplace. Typically, these products have been started based on needs these organizations have identified through their experience in service-based projects with different customers. While this is a good starting point for a successful product discovery, most of these organizations focus their product efforts around the knowledge they have acquired already and try to fit the product development into their existing structures and mindsets.

To create thriving product organizations however, leaders need to be aware of the differences between the service and the product domain in terms of company structure, mindset, people skills, and focus. This article presents an overview of the key characteristics that a product organization shall employ as compared to a pure service organization, particularly in the technology domain.

Product mindset

There is a fundamental difference between the mindsets required for a product and a service organization. In the latter, focus is on delivering a project within scope, budget, and time, and this imposes a rather short-term span – within the scope of the current project. Of course, on a top management level long-term vision for the organization most probably exists, but again it is focused on optimizing efficiency of operations, scaling, and successful execution.  In a product organization, the primary goal is launching a successful product on the marketplace, and gaining the returns from the investment made over the product’s lifecycle, which hopefully lasts years to come. It is not a one-time delivery effort – it is an ongoing exercise, in which we need a long-term vision and strategy related to the product itself to ensure that we are building the right product, and the investments we are making will bring us forward in the market.

Staying connected over a long period of time to a big vision means aligning the entire organization around that vision, engaging people with it, and building a different understanding of the purpose of the organization – we are not here just to execute a customer’s requirements, we are here to identify unmet needs and address them with a product that delights the customers. This means that we are an active part of the entire product lifecycle – from its discovery, throughout the development, launch, and subsequent continuous innovation, people in the organization are engaged and contributing with all their capabilities over a long period of time.

Finally, it all boils down to creating an end-to-end responsibility, an ownership for the product. While in a service organization we are the receiving end of requirements that somebody else defines and our responsibility is primarily to deliver on these requirements, in a product company we define the requirements, and we are responsible for the outcome, and this responsibility stays with us throughout the entire life of the product. We are there to keep listening to our customers, learn and adapt our product strategy and roadmap, and make sure that we are building the best product possible within the constraints of the business – not just efficiently, but also effectively, maximizing the return on investment.

Collaborative environment

Many service organizations are structured in functional areas according to the predominant delivery model that is adopted. Such structures are optimized for capacity utilization, and are based on strict specialization, which in a service delivery model might speed up execution. Key performance indicators usually measure process efficiency rather than outcome effectiveness.

Creating a product however, is an iterative collaborative effort. It requires joint effort from experts with different backgrounds early on in the product lifecycle. Product discovery, for example, is an exercise of quick experimentation and learning about the market to identify the burning needs and possible solutions that will later on become a product, which is not a linear process and requires a variety of skills and contributions. In this exercise, input from all parts of the value chain is important to shape the solution into a desirable, viable, and feasible innovation. Silo thinking and barriers to collaboration, such as focus on department’s specific goals and KPIs and not on the value the organization is providing as a whole, are detrimental to the learning experience, and prevent engagement with the vision. A product organization needs to be structured around the need for joint effort and collaborative learning. What is required is an agile and fluid structure that empowers people to connect, share, and work together as early as possible, and is measured and optimized around the common product vision and desired outcomes, rather than resource utilization.

In this structure, there is a special role for product management. A recent article by McKinsey focuses on the importance of the Product Manager in a product organization. The PM is the flagman of the endeavor, the “mini-CEO” for the product, who holds the vision, navigates the strategy, inspires and orchestrates execution throughout the entire product lifecycle. I will discuss the role of the Product Manager in more detail in a separate blog post.

When we talk about collaboration, the role of leadership is paramount. Leaders are the drivers of company culture, and their behaviors may enable or discourage collaboration among teams in the organization. An environment that tolerates joint work requires shared vision, continuous communication, common metrics of success, and empowerment of the different players to take initiative and drive decisions. The managers of such an organization need to lead with direction, and focus more on strategy and outcomes rather than control every step of the process. Control of execution shall be left more in the hands of the teams, along with the responsibility to improve collaboratively.

Process

In service organizations, the predominant process models are linear and work flow from one step of the process to the other based on elaborated project plans. In most cases, this is OK for projects with well-clarified requirements, clear deadlines and goals.

Product development rarely does fall into this description. As I wrote above, creating a product involves first of all identifying needs, and finding proper solutions to those needs. Requirements are rarely crystal clear – what is more, as we learn about our customers in the process of development, requirements may change dramatically, and we need to respond to those changes, so that we can launch a successful product. A linear plan-driven approach does not provide space for experimentation, learning, and adaptation, as it focuses on other metrics – time, budget, and fixed scope. When creating a product, we need to be agile at any point of the product creation, and our focus is on ensuring that we invest in the right things to maximize revenues and returns. Therefore, adopting principles, methods and techniques that enable focus on learning through quick feedback cycle to minimize waste and maximize value – such as design thinking, Lean thinking, Agile software development, is crucial to allow processes to support and not block proper product discovery and delivery.

Skills

Finally, a product organization requires different skillsets as compared to service organizations. We need to develop a number of skills both on business and technology side, such as:

  • strategic thinking and market knowledge for the key people who drive product development – product managers, key technology people, leaders
  • knowledge and understanding of the principles and methods that enable a learning organization focused on product creation
  • new technological paradigms that enable iterative product development and delivery
  • capabilities to use technology advancements such as big data to make product decisions
  • abilities to prioritize, manage risk, iterate over product strategies and roadmaps

Obviously, building the skillset requires strategic decision to prepare and transform our organization into a product company. It is also a first step towards building the proper mindsets and behaviors in people, giving them the needed capabilities to be successful in such a context.

One of the organizations that is driving the evolution of Software Product Management as a discipline is the International Software Product Management Association (ISPMA). It is an open non-profit association of experts, companies, and research institutes with the goal to foster software product management excellence across industries. ISPMA establishes software product management as a discipline in both academia and industry, and disseminates and maintains a Curriculum and a Certifiable Body of Knowledge (SPMBOK). The SPMBOK is documented in syllabi that are the basis for training courses and certification exams. The syllabi are available for free for all members.

Now we are excited to offer in collaboration with Innotivum Consulting the first ISPMA-based Foundation Level certification training in Eastern Europe (Bucharest, Romania) for product managers who want to take their skills on a next level and get certified, as well as for leaders who want to learn more about the path to creating a product organization. Read more about the training at http://leanify.com/spm-foundation-level-training-november-13-15-bucharest/.

The Difference between Product and Service Organizations
Tagged on:

Leave a Reply

Your email address will not be published. Required fields are marked *