TU-E5040 - Product Management D, Lecture, 4.9.2023-12.10.2023

THE TASK

Take the feature you specified in Assignment 1 and define the first development slice(s). The result should be a description of the slice of the feature, preferably with UI mockups to help you explain the difference between the full feature and the first slice.

If you want to have an alternative starting points, you pick any of the examples here.

THE OBJECTIVE

The goal of the assignment is to learn how to split features to smaller increments. The assignment continues from the Assignment 1, where you defined a feature based on a customer need, using job-to-be-done -framework. 

Any idea of a feature, regardless of the how well it is defined, is necessarily based on assumptions before it is tested in use. Building the whole feature on one go is potentially risky and may also be too expensive, and therefore, finding the smallest useful slices of functionality is a good practice to structure the development. 

Take the feature you specified in Assignment 1 and define the first slice(s) by considering (at least) the questions below.

WHAT IS A SLICE?

Any idea of a feature, regardless of the how well it is defined, is necessarily based on assumptions before it is tested in use. However, building a full feature in a single, uninterrupted process with all the required components is usually suboptimal. First, you lose the opportunity to test and refine the feature during the development process, which would help you to re-assess the assumptions and react to new information. Second, the feature could well be useful already in a limited format, and if shipped to customers, it could produce business value already during the development process.

The idea of slicing is to approach the development path as an order set of steps. Each step should produce as much use value as possible with as little development effort as possible. The most effective steps should be taken first (easiest and most valuable), and less valuable (harder or less valuable) later. In such approach, the first slice would be the smallest development effort needed that would produce first such version of the feature that would be useful for user (first version, not the full feature). Naturally, the definition of slices requires both customer understanding as well as understanding of the implementation. The value of each step comes from the customer’s needs, and the cost derives from the complexity and extent of the implementation effort. 

It's good to note that term “slice” is used here as a liberal interpretation of “vertical slice”, a concept in agile development. The general idea is the same, but note that agile terminology is a genre on its own. Check a few blog articles about vertical vs horizontal slicing to get the idea, but further dive into concepts and processes of agile are definitely among the first slices on the path to develop PM competence (meta-pun intended).

THE TASK IN STEPS

1. Evaluate your proposed feature (from A1) and refine it, if needed. Does your suggestion for the new feature in Assignment 1 define a functionality? If yes, use that as the basis of this assignment. If not, sharpen the definition. If you want to use some other feature for which you have sufficiently well-defined groundwork done, you can use that (or any of the alternative starting points).
   In any case, define the feature in your reporting.
2. Form a light sketch of an architecture for the feature[1]. What new functionalities and elements the feature requires, and what changes and additions this implies to the product[2]? 
   Consider this on the level that matches your know-how in terms of software development. If you are not familiar with the field, feel free to use ”black box” -architecture[3], that is, just describe what new  functionalities the implementation of the feature needs from the system.
3. Analyse the development path for the feature. Consider the following questions and assess what are the slices (the smallest useful increments) that you could and should implement when developing the feature:
   • What should you implement to eliminate the biggest unknowns and risky assumptions?
   • What can be left out from a minimal version?
   • Is there a "20% implementation" that gets you 80% of the value?
   • If you could ignore all error scenarios, what would be the simplest happy path?
   • Can you focus only on one persona / one segment of users?
4. Report the results. The result should be a description of the first slice(s) of the feature, preferably with UI mockups and associated development path that can help you explain the difference between the full feature and the first slice.
5. Return as a single pdf-file:  Report the results focusing on clarity and brevity. When formatting the reporting, consider a format that can function for a PM when leading the discussion of the product team on what the prioritize in development.
   Use a minimal number of pages (One page would be splendid). Detail the sources and potential notes on the last page.