www.cs.helsinki.fi

Product definition,product vision,

product life cycleTommi Mikkonen

Dept. Computer ScienceUniversity of Helsinki, Helsinki. Finland

tommi.mikkonen@helsinki.fi

Product definition, product visionProduct creation and product life cycleSoftware evolution view to productsScaling product managementFor further readingSummary and conclusions

Content

Product management

Components- Versioning: Which versions exist, how

to find old versions, etc. - Identification: Which component this is?

What properties it has?- Production: How to create a particular

component (which compiler version, whichflags, etc).

- Change management: How to preventsimultaneous changes, which changeshave been made, …

Configuration- Versioning: Which versions exist, how to

recreate old versions, …- Identification: Which configuration this is,

which components and component versionsare used by client x’s installation y …

- Production: How to build client x’sconfiguration a.b.c

- Change management: Which components(and their versions) a certain change willhave an effect on? Which configurations(and their versions) a certain change willhave an effect on? …

Practices, processes, etc.- Responsibility and privileges- How phase products move from one system/phase to next?- How new versions are approved and released?- How change proposals and error reports are made, managed and processed? - Archives and backups…

“A good or service that most closely meets the requirements of a particular market and yields enough profit to justify its continued existence.” - http://www.businessdictionary.com/definition/product.html

“The totality of goods or services that a companymakes available”- http://www.dictionary.com/browse/product

Software product definition

“For a mid-sized company’s marketing and sales departments who need basic CRM functionality, the CRM-Innovator is a Web-based service that provides sales tracking, lead generation, and sales representative support features that improve customer relationships at critical touch points. Unlike other services or package software products, our product provides very capable services at a moderate cost.” - https://www.joelonsoftware.com/2002/05/09/product-vision/(as proposed by Jim Highsmith Practice Director, Agile Project Management, Cutter Consortium.)

Software product vision

• For (target customer)• Who (statement of the need or opportunity)• The (product name) is a (product category)• That (key benefit, compelling reason to buy)• Unlike (primary competitive alternative)• Our product (statement of primary differentiation)

https://www.joelonsoftware.com/2002/05/09/product-vision/

Software product vision

Product life (US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction.)

Product life (US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT Chapter 1. Introduction.)

Great opportunities to create useless inventories!

https://en.wikipedia.org/wiki/Crossing_the_Chasmhttps://en.wikipedia.org/wiki/Product_life-cycle_management_(marketing)

Product life cycle management

World does not stand still at maintenance: iterations, versions, etc.(https://en.wikipedia.org/wiki/Systems_development_life_cycle)

… …

Methodologial vs. ad-hoc feedback loops

• Prototyping• Incremental development• Sprints• Lean startup

Prototyping (& partly also demos)

Goals

• Figuring out what is technicallydoable

• Validating designs and predicting large problems

• Communication, assuring management and other stake-holders

Attributes

• Cycle length: From hours to months

• Team size: From one developer to a team of developers

• Termination condition: Full stop once a technological solution is proven to be feasible.

Incremental development

Goals

• Provide value to the customers already during the project.

• Taking advantage of new technology.• Assuring users that the development is continuous and on-going.

Attributes

• Cycle length: Any given time that is needed to get a new increment done..?

• Team size: Software team (and the related stakeholders)

• Termination condition: When the new software asset/increment is considered done.

Sprints

Goals

• Responding to emerging user needs• Helping in execution and coordination of the work

• Improving the ways of working• Guiding to frequent evaluations of new parts of the system

Attributes

• Cycle length: One to four weeks• Team size: Software team• Termination condition: Calendar

deadline (1-4 weeks)

Lean startup

Goals

• Gathering justifiable evidence ifprofitable, scalable user needs exist.

• Evaluating if a hypothesized business model is feasible to satisfy the user needs.

• Learning by creating MVPs.

Attributes

• Cycle length: From days to weeks• Team size: From a single

developer to a whole softwareteam.

• Termination condition: Once the learning goal can be validatedwith statistically significant results.

Focus Motivation Goal Staff

Prototyping Feasibility and implemen-tability

Almost always technical in nature

Explore design space for a particular solution

individual developer, team of developers

Incremental development

Scoping the technical work feature-wise

Mix between business and technical aspects

Organize company operations as a whole in releases

Affects the whole organization

Sprints Scoping the technical work time wise

Liberate devel-opers from constant changes to a fixed set of features

Considers mostly development aspects.

Executed by a Scrum team up to 12 people; variations exist

Lean startup Learning and experimenting

Business oriented in nature.

validate a business hypothesis with minimum effort

Usually executed only by a minimal team

“More is better”?

http://upload.wikimedia.org/wikipedia/en/thumb/6/6b/Redkali3.jpg/220px-Redkali3.jpg

v. 2.0

v. 1.0

http://upload.wikimedia.org/wikipedia/commons/thumb/b/b1/Statua_della_Sirenetta-_2014-01-20_00-37.jpg/240px-Statua_della_Sirenetta-_2014-01-20_00-37.jpg

“Process of developing software, then repeatedly updating it for various reasons”“Over 90% of the costs of a typical system arise in the maintenance phase, and

that any successful piece of software will inevitably be maintained” - Fred Brooks

“Agile methods stem from maintenance-like activities (originally in and around web based technologies)”

- Wikipedia

Software evolution view to products

Lehman’s laws of software evolution(https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution)

S-type programs are those that can be specified formally;

P-type programs cannot be specified but an iterative process or procedure is used to find a working solution;

E-type programs are embedded in the real world and become part of it thereby changing it, and requiring a feedback system where the program and its environment evolve in coordinated fashion.

Algorithms, e.g. sorting

Process control, e.g. maintaining correct temperature

Systems that interact with people and other parts of their environment

Continuing Change. All E-type systems need continuous adaptation or they become progressively less satisfactory.

Increasing Complexity. Because all E-type systems evolve, their complexity increases unless work is done to reduce it.

Self-Regulation. E-type system evolution process is self-regulating with distribution of product and process measures close to normal.

Conservation of Organizational Stability. The average effective global activity rate in an evolving E-type system is invariant over a product lifetime.

Continuing Growth. The functional content of an E-type system must be continually increased to maintain user satisfaction.

Characteristics of an E-type system

Conservation of Familiarity. As an E-type system makes everything associated with it evolve, developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution. Because too rapid growth diminishes that mastery, the average incremental growth remains invariant as the system evolves.

Declining Quality. The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.

Feedback System. E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.

Characteristics of an E-type system

• Corrective – diagnosing and fixing errors, possibly ones found by users

• Adaptive – modifying the system to cope with changes in the software environment (DBMS, OS)

• Perfective – implementing new or changed user requirements which concern functional enhancements to the software

• Preventive – increasing software maintainability or reliability to prevent problems in the future

Types of upgrades(https://en.wikipedia.org/wiki/Software_maintenance)

Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems.

Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment.

Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability.

Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.

Types of upgrades(ISO/IEC 14764)

Maintenance specialists 35%High staff experience 34%Table-driven variables and data 33%Low complexity of base code 32%Y2K and special search engine 30%Code restructuring tools 29%Re-engineering tools 27%High level programming languages 25%Reverse engineering tools 23%Complexity analysis tools 20%Defect tracking tools 20%Y2K “mass update” specialists 20%Automated change control tools 18%Unpaid overtime 18%Quality measurements 16%

Maintenance factors (for/against success)Error prone modules -50%Embedded variables and data -45%Staff inexperience -40%High code complexity -30%No Y2K of special search engines -28%Manual change control methods -27%Low level programming languages -25%No defect tracking tools -24%No Y2K “mass update” specialists -22%Poor ease of use -18%No quality measurements -18%No maintenance specialists -18%Poor response time -16%No code inspections -15%No regression test libraries -15%

Vote: Does PO role scale?

Example: Mozilla connected devices process(https://wiki.mozilla.org/Connected_Devices/Product_Innovation_Process)

Example: The Long Tail (http://www.longtail.com/about.html)

Product Owner vs. Product management• Product Managers -> overall market success of their products, not just

delivery of software• Product Owner (agile/sw term) -> Small subset of the Product Management

Option #1: Product management picks up additional, tactical responsibilities of the Scrum product owner• Does not scale: agile teams require intense, daily tactical support.• Product managers usually not interested in the technical part

Option #2: Product owners assume some of the responsibilities of the product managers• Overlapping responsibilities; “Who decides what the product is supposed to

do?”• POs are unlikely to be trained or skilled in the other aspects of the traditional

product manager role

Scoping product management “in the large”

Option #3: Dual agile roles• market/customer-facing product managers

…. continue in their role along with most of their existing responsibilities, … adopt agile practices, including taking on a tighter relationship with the development teams.

• solution/product/technology-facing product owners … are either technically inclined product managers or business analysts, or development team members who are interested in that new role

• … assume the agile team product owner responsibilities but also take on a tighter relationship with product management

Scoping product management “in the large”

PO vs. PM: An agile interpretation

Agile product owner• Technology/team facing• Co-located (and also reports

to) development or technology• Focus on product and

implementation technology• Owns the implementation• Drives iterations

Agile product manager• Market /customer facing• Co-located (and reports to)

marketing or business• Focus on market segments,

product portfolio, return on investment (ROI)

• Owns the the vision and product roadmap

• Drives the release

Product vision:https://www.joelonsoftware.com/2002/05/09/product-vision/

Iterative cycles:http://scholarspace.manoa.hawaii.edu/handle/10125/41874

Software inventory (and how Trello was ideated):https://www.joelonsoftware.com/2012/07/09/software-inventory/

Lehman’s laws (of software evolution):https://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution

Scrum anti-patterns (as requested in the class):http://ieeexplore.ieee.org/abstract/document/6805443/

For further reading

Product vision needed to guide the development towards new versions

• To whom, why better than competition, why specia

Iterative approach is a practical must to learn & scope things as you go

Software evolution driving towards more and more complex designs

Scaling PO role up is practical, but requires discipline

Summary and conclusions