Part 1: Product management

We start from forming a rough map of the field. The premise for the product management is the notion that products are at the center of all value production of (nearly) all companies and other organisations. If the product is useful, it generates use value at the hands of the user (concretely and figuratively), and if the company is efficient in its operations, it can translate this use value to transaction value, and finally to operating profit.  

Taking the product at the center of attention, we can focus on three questions: 1) What should be considered when making decisions related to product, 2) who should do these decision and with whom, and 3) how the organization can develop its competences in developing and working with products. 

The first session presents the premise, and ask what is a product, and presents an overview of the field of product management.

(Regrettably, the very last part of Marko Oksanen's lecture was lost due to technical problems, and will be re-recorded in few weeks).

After the overview, we focus on each of the three key dimensions, and start from the one that is arguably the most fundamental: the needs of the users. If the product is not valuable for the users, there's no building a viable business on such a product. 

But who is the user, who is the customer, and how to figure out what they really need? These are the question that Udo Szabo explores in the following presentations.

The second key aspect of the product relates to feasibility. This aspect is often framed as "development", as one of the key issues for any organization is the ability to develop new products and enhance the existing ones. The "feasibility" is not limited to product development, but can be seen to entail operations and technology more broadly. In the end, also the production and maintanance need to be equally feasible on the long run. 

Nevertheless, modern PM organization tend to be ones that are in the process of creating or scaling software products, and therefore understanding of development teams and organizations is crucial for product managers.

Otto Hilska slices this topic into three focuses: How product development is organized, how teams work, and finally, how you ship a feature?

The third and concluding component of product are the requirements of business. "Business" is a broad category and more precisely it tends to cover the concerns related to viability of the product.

To be viable from the perspective of business, the product needs generate more in sales than what it's production costs. At early stages, this is seldomly the case, but even then, the foreseeable unit economics need to be healthy. In addition, the product needs to fit the overall portfolio and direction of the company, and also match the resources and capabilities of the organization.

Therefore, "business" actually captures more or less all the concerns of related to the company itself (plus the competition). Therefore, creation of priorities and sense of direction within the company is one of the key functions of product management.

Timo Herttua introduces this broad topic with two well-measured perspectives: unit economics and expectations of the "business" for the PM.

Bringing all the different requirements and perspectives together takes work and large amount of assumptions. Not everything acn be checked or even noticed, and any new product or feature is loaded with assumptions that may be right or wrong. These assupmtions expose the product to multiple different types of risks.

While risky, it's still better to build something, and then test whether the product is what's needed. It depends heavily on the type of product, but in many situations, the best way to manage these risks is to validate the product and choices in small batches.  Product roadmaps can be built to include both the development stages as well as the hypothesis testing.

Terhi Hänninen introduces the why, when and how of validation. This concludes the first part, arching from the introduction of the field to the components of the products, and ending here with how to validate the product as it slowly takes its form.