Start-ups are by definition small, and almost invariably everyone is too focused on making a go of it to worry too much about product management. But once a start-up gains a foothold in its market and begins to grow, making product management a priority becomes critical.
That’s a lesson we learned at Klipfolio, and it’s the topic of this blog. Here are six important lessons about product management I learned as Klipfolio’s Senior Director, Product Management and Documentation.
1. Introduce the concept of product management to your company
It’s hard to know exactly when you should make product management the responsibility of one person on your team, but the important thing is to be aware that you will need to do it at some point.
Klipfolio has grown tremendously over the last three and a half years - our employee count is up by a factor of six, our customer count has grown by a factor of approximately seven, and our monthly recurring revenue (MRR) is up by a factor of about nine. To top it off, our product release count has grown by almost a factor of 12 each year.
With so much growth in the number of product releases, it should come as no surprise that product management became a priority.
Product management was introduced when I came on board, more than three years ago.
I took over the responsibility for product management from the founders, and worked to align strategy and target markets, introduce new processes, and overcome a lot of bad habits. It’s not always a straightforward process, but it is possible for product management to thrive in the tempest of growth and change that is a start-up.
2. Don’t go it alone
Product success and priorities should not be the exclusive responsibility of a single person - the product manager. Because change can happen quickly, we found that there is huge value to having the primary stakeholders collaborating for constant alignment.
We created a team of people from Development, User Experience and Product Management to bring three perspectives to the table at once and help balance the trade-offs between time, functionality and cost/resources.
Our structure ended up being like a three-legged stool: If one department is not in the room, the context is missing and things tend to tip.
We have found this partnership approach so useful, we have replicated it in teams as we have grown.
We get together at least once a week as the leaders for the product organization. At the team level, the people in the partnership are connecting pretty much daily.
3. Learn to balance the short-term priorities and the big picture
We went from about eight-week cycles to releasing almost every day, and sometimes twice a day. We will have over 200 releases this year vs. 14 the first year I was with Klipfolio.
Over time, there’s been an incredible acceleration in the need for stories and requirements. Inevitably, tasks get broken down into smaller increments. With this shift to more agile development, we have a prioritized list being picked up in two-week sprints. This allows for much more flexibility to redirect effort to areas requiring additional focus, and to quickly shift priorities.
However, the need for a more traditional roadmap remains. The management team, board of directors and marketing all want to see the longer-term plan. Having that longer-term plan also helps keep an eye on the big beats we want to achieve in the future. This provides a target for teams to aim for, generates urgency and excitement, and helps align teams behind our vision for the future.
We have chosen to balance both needs, and the roadmap evolved to ensure the high-level themes of what we want are prioritized. However, more fleshing out happens as things come closer.
This has allowed us to react as we found competitors jumping into our space and we needed to adjust quickly.
4. Experiment and adapt processes
With all this change, you should expect to learn more and change as you go.
We have built in a culture for experimentation that goes from tracking data on our product with MixPanel, to conducting A/B tests on functionalities like tours and onboarding and regular testing and adjustments to pricing models for optimization.
We have also been experimenting with processes to design, mock up and test new ideas and concepts. Over the past few years, we have used a number of approaches, including:
- Writing traditional requirements documents
- Enhancing requirements with user stories, something that has evolved and improved over time as other departments got more involved
- Following design thinking and creating journey maps
- Experimenting with user story mapping based on Jeff Patton’s book
- Trying design sprints (developed at Google Ventures)
- Tailoring design sprints for specific projects
These tests and experiments have brought in new concepts and excitement, not to mention more alignment and acceleration! However, beware of blindly following the patterns without regard to your situation, cultures and mindsets. You could end up creating the impression of being too rigid (the “stick to the process” mentality) rather than agile. We are currently blending a number of concepts from across the various approaches to fit with our culture and teams.
5. Grow with development
This feels like motherhood and apple pie issue - as the Dev team grows, so does their throughput, and the demand for a higher velocity of requirements and demands on your time. Nevertheless, it bears marking out as an important factor in product management.
You need to ramp up your capacity beyond just the development team. The biggest challenge for me was giving away the exciting projects to work on. I consciously gave the most exciting things to my team. My objective was to keep them engaged, enthusiastic and focused.
I’m also not big with “command and control” as an approach to enabling the team. I did find the more we grew and the increased demands on our time, the more we needed to have enough context to make decisions and then run.
We grew from one Dev team, one PM, and one UX to having four teams - each led by a partnership between Dev/PM/UX. We replicated the three-legged-stool of Dev/PM/UX for each team. They are each running version of design sprints with user story mapping.
6. Align product manager strengths with their projects
All job descriptions for a product manager will have all the common elements about speaking with customers, distilling requirements, driving the priorities, etc.
However, the types of skills needed may vary depending on the project, or product or company. For example, outside of the general skills of a product manager, there are a few common background skill sets that can help a product manager. The three that jump to mind are UX or design, technical or development, and business.
Inevitably, product managers will have some skill in each of these areas; however, as with personality tests, their strengths will gravitate towards one or two of those areas, but rarely all three.
We happen to have been lucky to have a really strong UX team, so the emphasis as we look at product managers is not on their design skills.
That said, we do have different areas for our product offering where being more business or technical savvy can be an asset. I mention this because over time, we have occasionally had our team shift focus areas. (Did I say we were living in a tempest?) During one of these shifts, we had a mismatch - one product manager with more technical tendencies was put in an area where being business savvy was the key to success. The product manager made a ton of progress and the area took some great leaps. However, there was an impact on morale, team cohesiveness, and such.
I love that we have an open dialogue in the team, and the product manager raised it in a one-on-one. Shortly afterwards, we had another shuffle that led to a better alignment with the employee’s strengths/tendencies.This change made a huge impact on the product manager and the person’s success profile in the company, among other things.
Those are the lessons we’ve learned. I hope you find them useful.
Scott Lawrence is the Senior Director of Product Management and Documentation at Klipfolio.
Originally published October 31, 2017, updated Jun, 18 2019