In-Class Topics

Product Focused Questions

• Who will use this?

• Why will they care?

• What can it do that people will pay for?

• What features are most important?

• How does everything fit together?

People Focused Questions

• Who is it for?

• Why does it matter to them?

• What can they do that they couldn’t do before?

• What features do they need to do that?

• How do those limited features fit together?

Why do we build products?

• delight customers

• get lots of them signed up

• Make a lot of money

• Realize a big vision; change the world

“Decide and Follow the Plan”

•Build a great product with enough features that increase the odds that customers will want it

•Problem: no feedback until the end, might be too late to adjust

“Release early, release often”

•Get as much feedback as possible, as soon as possible

•Problem: run around in circles, chasing what customers think they want

What do you want to learn first?

If customers will buy your product

Validated Learning

A process in which one learns by trying out an initial idea and then measuring it to validate the effect. Each test of an idea is a single iteration in a larger process of many iterations whereby something is learnt and then applied to succeeding tests

Minimum Viable Product

•The minimum set of features needed to learn from early evangelists – visionary early adopters

MVP Principles

• less is more in development

• the most boring feature is the most important one

Pretotype steps

1. Proposal

2. Smoke test

3. Fake demo

Proposal

a document describing the solution

Smoke test (Twittr)

landing page to test interest

Pretotyping

A way to test an idea (a hypothesis) quickly and inexpensively by creating extremely simplified, mocked or virtual versions of that product to help validate the premise that "If we build it, they will use it."

Prototyping

focuses on a model for building the product.

Types of Pretotypes

• in person interview/proposal

• smoke test: landing page + adwords

• explainer video

• fake door

• pinocchio (mockup)

• mechanical turk/wizard of oz

Pivot

A structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engine of growth.

Pivoting Rules

1.Successful pivoting is a function of your employees – there is only so much change possible

2.Swinging for the fence rarely works (e.g., focus on a different target, not a completely different product)

3.Timing and externalities matter more than you think (e.g., post 9/11, being first, etc.)

4.Success comes from incremental gains, not Hail-Mary’s

Zoom-In Pivot

A single feature becomes the whole product

Zoom-out pivot

The whole product becomes a single feature of a larger product

Customer segment pivot

Good product, bad customer segment

Customer need pivot

Responding, or a completely new product

Platform pivot

Change from an application to a platform, or vice versa

Business Architecture pivot

High margin, low volume. Low margin, high volume

Valure capture pivot

changes in the revenue model

Engine of growth

Picking how to grow: Viral, sticky, and paid…

channel pivot

How the product is delivered to customers

Technology pivot

New technology improves the competitiveness

Unified Modeling Language (UML)

• Has syntax and semantics which convey meaning, understanding, and constraints

• Not a programming language

• 13 graphical notations supplemented with text

• Use what you need

• Best used in large and complex projects spanning a length of time

• Probably a burden in small projects

Use Case - A UML Diagram

•Requirements analysis phase

•A case of a use of the system / product

•Describes the system’s actions from the point of view of an “actor” (i.e., a user, persona, etc.)

•Specifies one aspect of the behavior of a system, without specifying the structure of the system

Use case v. User stories

Use case: focus on the interaction between the user and a process in the system. Can be a big functionality

User stories: functionality the user wants.  Focus is on small stories that can be developed in one sprint

How do we capture use cases?

•Start with narrative (each system high-level functionality is a “use case”)

•Use case diagram

•This is a very simple diagram involving 3 symbols (for the purposes of this class), and a connecting line

Use case diagram: Actor (user/persona)

•External entity outside the domain of the system we are modeling

•Initiates a use case

•Gets some measurable benefit from that interaction

Use case diagram: a “use case”

•Reflects a high-level functionality of system

•As such, use cases must be initiated by actors

•Detailed documentation elsewhere; only represented on diagram graphically

•Starts with a verb

Use case diagram: “The system”

•Shows the system boundaries

•Advanced diagrams will have many boxes (as releases); we will just use one for class purposes

Complete use case diagram

Why create a use case diagram?

• show the big picture

• customer can relate

• developers can quickly access functionality and risk

• advanced diagrams will be more complex

Use case interactions

• An interaction is a specific instance of user-system exchange (we draw a line between the use case and the Actor)

• Examples: withdrawing money from an ATM is the use case (other things implied by this)

  •PIN correctly entered

  •PIN incorrect

  •Insufficient funds

  •ATM out of money

Important use case notes

• should involve some documentable interaction between the actor and system

• must have at least one Actor (user)

Getting ___ right is the hardest part of software developement

requirements

Source/sink might consist of the following:

•Another organization/organization unit which exchanges data with the focal system

•A person who interacts with the system (customer of a banking system)

•Another information system

___ to a process are always different than ___

inputs; outputs

Objects always have ___

a unique name

Miracle

no process can have only outputs

Black hole

no process can have only inputs

Processes must have ___ labels

verb

Data cannot move directly from one __ to another __ .They can be separated by inserting a _

data store; data store; process

Data cannot move directly from an outside __ to a __. It must be moved by a __

source; data store: process

Data cannot move directly to an outside __ from a __ -- it must be moved by a __.

sink; data store; process

Data store must have a __ label

noun

Data cannot move directly from a __ to a __.  It must be moved by a process.

source; sink

Source/sink must have a __ label

noun

Fork

means that exactly the same data goes to two different processes or data stores.

Join

means that exactly the same data comes from two different processes and data stores.

Data flow rule

• A data flow cannot go directly back to the same process it leaves

• A data flow to a data store means update (delete or change)

• A data flow from a data store means retrieve or use

• Noun phrase label

candidate key

an attribute that uniquely identifies each instance of an entity type

Identifier

a candidate key that has been selected as the unique, identifying characteristic for an entity type

Required attribute

attribute that must have a value for every entity instance

Optional attribute

attribute that may not have a value for every entity instance

Composite attribute

attribute that has meaningful component parts

Derived attribute

attribute whose value can be computed from related attribute values

One

Many

One (and only one)

Zero or one

One or many

Zero or many

Rules for stopping decomposition. Stop when:

Process becomes a single decision or calculation.
● Data store represents a single entity.
● Users do not need more detail.
● Data flows do not need further splitting.
● Each business form or report is shown as one data flow.
● Each menu choice has a separate process.
● More documentation adds no value