The document provides guidance on planning product development. It discusses establishing goals and specifications, assembling cross-functional teams to work on specs, estimating costs, creating roadmaps and schedules, daily standups to review progress, testing approaches, managing pivots and iterations, prioritizing features, and scaling processes as teams grow. The overall message is that each product and team is unique, so planning methods should be tailored accordingly and focused on achieving results.

1. Don’t forget to plan!
Mass Technology Leadership Council
June 21, 2012
Geoff Scott

2. Input
• Pipelines – A stack ranked list of goals/features in a particular vertical.
(i.e. retention, revenue, operations, etc… these items require specs.)
• Specs – Critical to building out most aspects of a product. Includes
expected outcomes, goals, user stories and flows. Specs have their
own mini production schedule.
• Resourcing – Pods: A group of cross departmental recourses
assembled to work autonomously (spec  delivery) on a given
vertical.
• Costing – Preliminary estimates given by department leads to gauge
scope prior to kickoff (one pagers) and actual bids by the developer on
a the task level once a spec is signed off.

3. Output
• Roadmaps – A high-level sprint plan. Should give you a sense of
cadence across your verticals. A cone of uncertainty that you can
pivot from.
• Gantt Charts – Allows you to identify pileups, reviews, releases,
dependencies, etc…
• Daily Reviews – What is ready today? This is where iteration
happens.
• Branching Architecture and Testing – Test early and in the right
place. Establish cultural methodologies for pulling, pushing and
merging content and code. Put the proper sign offs in place.

4. Pivots and Iteration
• Requires fuel! This does not happen automatically and does not run
itself. Stakeholders and drivers need to take an active role in the
process.
• Horse Trading – Know how you are affecting the larger plan and
what’s the impact. It can sometimes be a complex problem that
requires two to three moves to accomplish a shift.
• Thrash – Bad for morale and is not productive. Manage up, as well
as down. Hold people accountable, not only for the work they do, but
for the change they drive.

5. Pivots and Iteration
• What’s the ROI? You have a hypothesis and an expectation around
your analysis and goal, but is your goal worth the resources required
to achieve it?
• Stack rank – Forcing people to prioritize their requests/motivations
seems obvious, but it’s value can’t be underestimated.
• It’s about results – Specs and schedules are merely guides. The
rubber hits the road with actual integration and the product itself.
Review early and often; keep teams small and focused.

6. The Size of an Idea
• Decide what your motivations are:
• I’m not sure? Build the minimum viable product; tier it, test it and
iterate.
• Scope with time. i.e. We should not spend more than X time or put
more than Y people towards this.
• The whole enchilada. Call BS. Tier it, test it and iterate; however,
sometimes it’s the truth.

7. One Size Does Not Fit All!
• Your team is made up of unique individuals and your product is the
sum of many different parts.
• What phase are you in? Early on, small teams may not require much
process at all. Add layers, as needed, while your team scales.
• Do what works for you. Scrum, whiteboards and sticky notes, green-
hopper, burn-downs, Gantt charts and waterfall models, etc… I use
them all.