This post first appeared on the Founder Fuel Blog
Early stage startups don’t generally need a discrete product management function, a point I’ve made here. As startups scale, however, most do add product managers to help them deal with increased complexity. Like any major organizational change, the process of adding product management to a scaling startup is at once transformative and full of challenges.
At Frank & Oak, a Montreal-based e-tailer, we’ve recently gone through this exact transition. As Head of Product Management, I’ve worked with our Founders and Head of Technology to manage the change, focusing on four key areas: defining the product manager (PM) role, setting a weekly rhythm, establishing key operations, and solidifying our tools. The results are a work in progress, but I hope nonetheless worth sharing here.
PM ROLE
When introducing the PM role, it was important for us to communicate clearly but iteratively. Not everyone has the same idea of what a product manager does, so we tried to be specific about what tasks PMs could own while sharing a vision for what the role could accomplish. At the same time, we allowed the role definition to coalesce over a few rounds of coffee chats, emails and formal meetings. By taking an iterative approach, we were able to customize the PM role to the specific organizational and team context at Frank & Oak.
Introducing the PM role also meant managing its perceived downsides. The addition of product managers can feel disempowering: developers suddenly have less control over feature definition and priority, while stakeholders have less access to the developers who solve their problems. While these perceptions can be discussed, we found the best approach was to simply show the value of the role with great specs, clear prioritization, prompt action on bugs and so on. When it comes to selling the vision of product management, actions definitely speak loudest.
WEEKLY RHYTHM
In an office, a week is a meaningful block of time, with its own natural rhythms. This makes it an ideal vessel for building a product team culture. At Frank and Oak, we now start each week with a 30 minute Monday Morning Kickoff. The Monday Kickoff was especially useful during the first few weeks of our new organization as we were iterating on the PM role and product team relationships. It remains our forum of choice for addressing key process issues, maintaining cross-team communication, and setting a good tone for the week. To soften the blow of starting Monday morning with a meeting, we serve free breakfast. St. Viateur bagels make culture change much tastier.
The focal point of the Monday Kickoff is the No Fail Goal, a cultural element we borrowed from Pollenizer, an Australian startup studio where I worked prior to joining Frank & Oak. A No Fail Goal is a non trivial task or milestone that can be closed in one week’s time. The goal is announced on Monday and results are tracked the following Monday. It’s a simple process, great for clarifying priorities and motivating teams without a lot of process overhead. The practice was designed for Pollenizer’s 3-person startup pods, but it’s translated extremely well to the complexity of a scaling startup.
To close the week, we’ve adopted another Pollenizer specialty, Drinks and Demos. On Friday at 4 PM, we buy beer and chips and invite people to present their designs, feature launches, test results, data insights and so on. Originally created for the product team, the session now extends across functions and serves as a nice capstone for the week’s work. It’s also a good forum to introduce new hires and entertain guests.
KEY PROCESSES
PM’s spend a good deal of time creating processes that support the work of developers and designers. In a scaling startup, new process layers are a double edged sword. On the one hand, team members appreciate that business growth requires bureaucratization. On the other hand, no one really loves bureaucracy. Like the PM role itself, introducing process is ultimately about showing value. Simply put, process should make people’s lives better. Persistence is also crucial, as some processes take time to bear fruit.
One process area we looked at early in our reorganization was issue tracking. It may seem obvious that developer work should always be tracked, but in a fast moving startup many things “just get done”. Ensuring that user stories get written for all development work can therefore be a fundamental culture change. It’s well worth the effort of course, and in our case we found a few weeks were all it took until consistent issue tracking was second nature.
Another process area we have worked to solidify is release rhythm. With the exception of our mobile team, we have not introduced formal sprints, so our release process boils down to weekly backlog reviews, PM-driven QA, and code pushes as needed. This approach provides flexibility, low process overhead, and the gratification of getting code live quickly. It does lack the rigor of more formal approaches, a limitation we try to make up for in part with the weekly No Fail Goal.
As our basic development cycle has solidified, we have invested more time in building a product roadmap. To build co-ownership of our first roadmap, we held broad-based brainstorming sessions followed by regular communication as the plan took shape. Our first roadmap projected out for 3 quarters. It was a great exercise, but it did not produce a stable operating plan. We are now moving to a 90-day prioritization cycles as inspired by the process run at Pandora.
Tying in with our 2014 goal setting, we are also making a bigger push on metrics. Beyond solving technical problems like incomplete data instrumentation and non-unified data sources, we’ve found that becoming data driven is also mostly about cultural change. In an early stage startup, decisions happen quickly and are often based on intuition and authority. As our product team matures, we are working to make sure that proper data is available, understood and at the center of goal setting and decision making. One project we’re still working on is metrics screens around the office so that key statistics are visually present at all times.
TOOLS
Like any organization, our tools express and reinforce our team culture. Here’s a list of some of the key tools we’re using:
- Issue Tracking – We use Pivotal Tracker for issue tracking. It’s a great piece of software, though the fit has been awkward at times since we are not running sprints or closely tracking velocity.
- Wireframing – We use balsamiq for wireframing. It’s a fantastic tool with an easy learning curve. Our UX process is a mix of wireframing and direct design in Photoshop and Illustrator.
- Analytics – Thanks to our amazing BI maestro, we’re currently transitioning our analytics from RJ Metrics, which is a great dashboarding tool, to Looker which is much more powerful for ad hoc analysis.
- Documentation – We use google docs for just about everything. There’s still a few .ppt and .doc files that get passed around, but we’re on a mission to phase out all attachments that don’t end in .xls.
- Testing – We use a mix of optimizely, in-house tools, and taplytics for mobile. We track all tests in a single archive and circulate results regularly via email and in meetings.
- Group Chat – We use hipchat to foster communication. It’s been a big improvement over gchat and the price is competitive compared to some of the other solutions we looked at.
- Archiving – We have been trying to crowdbase as an archiving tool, though with limited success. This has less to do with the tool and more to do with the challenges of implementing our documentation plan in a fast-growing company.
WHAT’S NEXT
In a fast growing startup, it’s hard to say what’s next. We have big plans though, so please stay tuned for another post in a few months with updates from Rue St. Viateur.
—–
Thanks to our content guru Kirsten Weisenburger for reading a draft of this article and to our PM team Eric Azran, Nima Gardideh and Jeff Talajic for their comments and for being awesome.