Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Product Management at Contactually

1,438
views

Published on

Published in: Technology, Business

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,438
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
15
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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