1. PRODUCT MANAGEMENT
AT CONTACTUALLY
August, 2013

2. WHY WE’RE HERE
We’ve spent a lot of time thinking about how best to
manage a growing product, and a growing organization
behind it.
This document captures where we currently stand in
our process.

3. BEFORE: THE DARK DAYS

4. 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
Icebox.
• Periodically, it would be gutted, with swaths of submitted
items being deleted, pissing people off.
• The backlog grew to be insane.
• Engineers wouldn’t be pushing the product forward as
much as chipping away at an ever-growing pile.

5. 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
important.
• Keeping engineers focused with weekly sprints.
... this actually helped, but it was still unclear what they were best tasked
with.

6. IT DIDN’T WORK
• As an open organization, product
development was a black box,
frustrating stakeholders.
• Everyone was out of sync, even
engineers.
• The product was not moving
forward.

7. 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, staff, 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?

8. THE RESULTING
FRAMEWORK

9. WARNING
THIS IS WORKING SO FAR FOR US.
WILL IT WORK FOR YOU? WHO KNOWS.

10. INGREDIENTS
• Product Vision Document
• Iteration Planning (Google Spreadsheet)
• Trello
• Good ‘ol Pivotal Tracker

11. THE PRODUCT VISION
• PDF or Powerpoint.
• Speaks to the overall vision of your
company
• Outlines what features are needed.
• Review and modify quarterly as you
learn more.
• Should be used to evaluate every
upcoming feature and proposed
enhancement - how does it fit in?
Statement
User Needs
Functional Needs
Features

12. ITERATION PLANNING
• Google spreadsheet that, for each sprint, states who is going to be working on what
overall feature.
• 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.

13. TRELLO
• Best solution we’ve found for flexible 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 filter out theirs (not easily- Trello fix this!)
• This is used daily.
Here’s how we’ve laid out Trello Boards

14. PIVOTAL TRACKER
• Pivotal is what engineers are/will be working on.
• Pivotal should only contain:
What is being worked on this sprint.
Bugs.
Technical Debt.
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.

15. AND NOW, WE DANCE.

16. LARGER PRODUCT
DISCUSSIONS
• 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 fit?
• 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?

17. SPRINT PLANNING
MEETINGS
• 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?

18. 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.
• Work.
• 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.

19. 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).

20. 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.

21. EVERYBODY’S HAPPY.

22. JUST REMEMBER

23. WE’RE HUMAN
• Deviations will happen. Products are flammable. 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 offended.
• Above all else, communicating + setting expectations is key to product
development.

24. CONTACTUALLY.COM
Prepared by Zvi Band, CEO
zvi@contactually.com
@skeevis
Join us, we’re hiring.