The first list overrides the second list. When in doubt, ask the Product Strategist.

Rationale

Launchpad regularly develops new features. We'd like to make sure that these features are implemented well, and that they are what our users actually need.

This process is successful if it helps us make exactly what users want, with no wasted extra features and no crappy pain points in the new interfaces.

In particular, we want to have feature definitions that:

Produce requirements for use by Launchpad developers

Can inform QA

Make it easy for timely input from people who are interested

Do not specify implementation approaches

Triggers

This process is triggered when you want to do a new feature, or when beginning work on a feature squad.

Roles

Product Strategist

Analyst

Stakeholders

The Product Strategist triggers this process and approves any output from it.

The Analyst is the author of any of the outputs. The Analyst can be any Launchpad developer or community member. The Strategist should be available to take the role of doing the actual writing, particularly if the Analyst finds it a burden. The thinking must come from the Analyst.

Inputs

The input should include as many user stories as possible with a form like:

As a $PERSONI want $FEATUREso that $BENEFIT

There must also be a list of Stakeholders — people who are actually interested in the feature.

The input should also include a written reason as to why we are working on this feature right now, instead of other features that we could be doing.

Talk to someone

Talk to someone, anyone. Talk over the phone and make notes with something like Gobby, or just on the wiki page directly.

Good people to talk to include Stakeholders and the Product Strategist.

Talk to the product strategist

Just in case you missed it, you should really talk to the Product Strategist.

Start adding constraints

A constraint is some condition that the solution must satisfy. The constraints listed here should be:

specific, avoid “motherhood and apple pie” statements such as “feature must be awesome”

testable, it should be clear when the constraint is satisfied

But actually, the more the merrier. Get them down first, get them right later.

It's important to work with Stakeholders at this stage. Remember to ask “why” a million times over so that we get the right constraint down.

These constraints should not specify a solution.

Often, it's very helpful to describe what things are not included as part of the feature.

Jot down sub-features

Thinking about the problem will probably lead you to discover sub-features, smaller things that can be delivered independently and will add value while building up to reach the bigger story.

These sub-features can have their own feature document / blueprint thing, or they can go down in this document.

Either way, each sub-feature should go through a process very similar the one of the overall feature.

Delete any unused sections

It makes the document easier to read.

Get it reviewed

Move the link to the proposal on LEP from "Drafting" to "Needs approval".

Review the output with the Product Strategist, who will move it on to "Ready to code" or bounce it back to "Drafting".

This process is complete when we feel we have enough information to start designing a UI. Remember the process is iterative. It's expected that the actual constraints will be better understood as we start to design & implement.