Product Management at Contactually

download Product Management at Contactually

of 24

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Product Management at Contactually


2. WHY WERE HERE Weve 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 o. The backlog grew to be insane. Engineers wouldnt 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 DIDNT 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, 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? 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 t 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 weve 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. Heres how weve 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 t? Review Iteration Planning: When should we work on it? At end of meeting: Do we have buy-in that were 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 well 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 WEVE 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. EVERYBODYS HAPPY. 22. JUST REMEMBER 23. WERE HUMAN 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 wont be oended. Above all else, communicating + setting expectations is key to product development. 24. CONTACTUALLY.COM Prepared by Zvi Band, CEO @skeevis Join us, were hiring.