Product Management at Contactually
-
Upload
contactually -
Category
Technology
-
view
1.515 -
download
1
Transcript of Product Management at Contactually
PRODUCT MANAGEMENT AT CONTACTUALLY
August, 2013
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.
BEFORE: THE DARK DAYS
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.
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.
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.
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?
THE RESULTING FRAMEWORK
WARNINGTHIS IS WORKING SO FAR FOR US.
WILL IT WORK FOR YOU? WHO KNOWS.
INGREDIENTS
• Product Vision Document
• Iteration Planning (Google Spreadsheet)
• Trello
• Good ‘ol Pivotal Tracker
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
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.
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
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.
AND NOW, WE DANCE.
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?
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?
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.
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.
EVERYBODY’S HAPPY.
JUST REMEMBER
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.