THE BIG PILE OF WORK
• All development, planning, and prioritization was done
through Pivotal Tracker.
• All upcoming development, planned development, bugs,
team feedback, user feedback was thrown into the
• Periodically, it would be gutted, with swaths of submitted
items being deleted, pissing people oﬀ.
• The backlog grew to be insane.
• Engineers wouldn’t be pushing the product forward as
much as chipping away at an ever-growing pile.
WE ALSO TRIED
• Keeping a product roadmap in Excel.
... which would periodically feed in to Pivotal, but just created more work.
• Collecting user feedback in Asana.
... which created an endless pile of things we never got around to.
• Weekly product meetings.
... which were hour-long arguments about which Pivotal task was more
• Keeping engineers focused with weekly sprints.
... this actually helped, but it was still unclear what they were best tasked
IT DIDN’T WORK
• As an open organization, product
development was a black box,
• Everyone was out of sync, even
• The product was not moving
WHAT WE NEEDED
• A open system so all stakeholders (design/marketing/sales) could understand what was
being worked on and buy in.
• An accountability system, so users, staﬀ, investors, advisors would ensure their input
was at least received and considered.
• Engineers could understand what their goals were, and work autonomously.
• Balance our long term vision with short term priorities and immediate needs.
• EASY, RIGHT?
THE PRODUCT VISION
• PDF or Powerpoint.
• Speaks to the overall vision of your
• Outlines what features are needed.
• Review and modify quarterly as you
• Should be used to evaluate every
upcoming feature and proposed
enhancement - how does it ﬁt in?
• Google spreadsheet that, for each sprint, states who is going to be working on what
• Each tasking (cell) should be either new feature dev, new iterations of additional
features, or core platform (bugs, technical debt, misc)
• Also states who (outside of eng. team) will be responsible for testing.
• Priorities change? Development taking too long? Look at and modify this document.
• Reviewed each sprint to plan for upcoming sprint.
• Best solution we’ve found for ﬂexible organization + management.
• A identically-structured board is created for each major feature.
• Initial specs, user feedback, and team suggestions are posted in here.
• Trello allows for discussion/voting/tracking of individual items.
• Everyone can see the status of all items, and ﬁlter out theirs (not easily- Trello ﬁx this!)
• This is used daily.
Here’s how we’ve laid out Trello Boards
• Pivotal is what engineers are/will be working on.
• Pivotal should only contain:
What is being worked on this sprint.
Internal needs + misc.
• Icebox is triaged regularly, backlog is monitored for what
should be back in Trello or prioritized.
• Updates from Pivotal are fed into Hipchat
• Pivotal is used by engineers every hour.
• Happens on a monthly basis.
• Discuss the larger strategic moves, metrics, and where we are at in the product vision.
• What are the top 3 priorities each month for the next 90 days?
• Compare against product vision: Where does it ﬁt?
• Review Iteration Planning: When should we work on it?
• At end of meeting: Do we have buy-in that we’re working on the right things?
• Review Iteration Planning to review upcoming sprints.
• Triage appropriate Trello Boards:
• Accept or Reject User + Team Feedback.
• Review User Feedback + Future Enhancements lists: Move appropriate items
into Next Iteration (what we’ll do the next time we work on this feature) or Future
Enhancements (we agree this is important to do, but not immediately)
• Ensure full team is aware of results and plans accordingly (aka queue up design, brief
feature tech lead on context, etc).
• At end of meeting: Do we have a clear idea of exactly what will be done next sprint?
• Tech Lead on particular feature opens Trello,
moves Next Iteration to Under Development,
creates stories in Pivotal.
• Tech lead meets with designer to ensure all
creative assets are understood.
• Tech lead works with test lead(s) for acceptance.
• Sprint progress discussed at daily stand-up.
• Sprint Show and Tell reviews both what was built
this sprint, and what is being done next sprint.
BUGS AND FEEDBACK
• Repeat 30X: “Bugs go into Pivotal, Feedback into Trello.”
• Bugs are put into the Icebox in Pivotal, engineering lead triages and prioritizes
(including modifying the current sprint)
• Feedback, from major suggestions to minor tweaks, are put straight into Trello.
• For major features, full-team internal test/feedback sessions + Alpha User test group
are still utilized, with results being triaged between Trello (good idea) and Pivotal (great
idea, we really should do this now).
WHAT WE’VE FOUND
• By keeping all of this open, everyone can review and understand at varying levels what
is being done.
• Discussions can be bounded appropriately (what is our long term vision vs. what are
we working on the next 90 days vs. what improvements are we making to this feature)
• Everyone understands what tools they should interact with (e.g. engineering is handled
through pivotal, user feedback captured in Trello, etc).
• We can ensure the product is moving forward.
• Deviations will happen. Products are ﬂammable. Development will take longer. This
process is meant to be accommodate and be as resilient as possible.
• YMMV: Take this as a baseline, useful ideas, or an example of what never to do. We
won’t be oﬀended.
• Above all else, communicating + setting expectations is key to product
Prepared by Zvi Band, CEO
Join us, we’re hiring.