Thriving in a tempest: What we learned about product management during Klipfolio's start-up phase

Start-ups are small by design, and almost everyone inside one is too focused on survival to think much about product management. But once a start-up gains a foothold and begins to grow, making product management a priority becomes critical.

That's a lesson we learned at Klipfolio. Here are six important lessons about product management I learned as Klipfolio's Senior Director, Product Management and Documentation.

1. Introduce product management as a formal role

It's hard to know exactly when to make product management one person's responsibility, but the important thing is recognizing that moment will come.

Klipfolio grew tremendously over three and a half years: employee count up by a factor of six, customer count up by roughly seven, and Monthly Recurring Revenue up by about nine. Product release count grew by nearly a factor of 12 each year.

With that pace of releases, product management had to become a priority.

Product management was introduced when I came on board, more than three years ago. I took over from the founders and worked to align strategy and target markets, introduce new processes, and replace a lot of habits that no longer served the company. It's not always a clean process, but product management can thrive in the tempest of growth that is a start-up.

2. Don't go it alone

Product priorities should not rest with a single person. Because change happens fast, having primary stakeholders in constant alignment is worth far more than one person trying to hold everything together.

We built a team drawing from Development, User Experience, and Product Management to bring three perspectives to every decision and help balance trade-offs between time, functionality, and resources.

The structure became a three-legged stool: if one department isn't in the room, context is missing and things tip.

We found this partnership approach so useful that we replicated it as we grew. Leaders across the product organization meet at least once a week. At the team level, the people in each partnership connect almost daily.

3. Balance short-term priorities with the big picture

We went from eight-week release cycles to releasing almost every day, sometimes twice a day. We had over 200 releases in 2018 compared to 14 in my first year at Klipfolio.

Over time, the demand for stories and requirements accelerated sharply. Tasks got broken into smaller increments. With more agile development, we work from a prioritized list picked up in two-week sprints. That gives us the flexibility to redirect effort quickly when priorities shift.

That said, a longer-term roadmap still matters. The management team, board of directors, and marketing all need to see the plan beyond the next sprint. The roadmap also keeps the bigger milestones visible, generates urgency, and helps align teams behind a shared vision.

We chose to balance both. The roadmap holds the high-level themes we want to pursue, with more detail added as work comes closer. That balance let us respond when competitors moved into our space and we needed to adjust fast.

4. Experiment and adapt your processes

With constant change, expect to keep learning and adjusting.

We built a culture of experimentation: tracking product data in Mixpanel, running A/B tests on onboarding and tours, and regularly testing pricing adjustments. We also experimented with how we design, mock up, and test new ideas.

Over the past few years, we tried a range of approaches, including:

• Writing traditional requirements documents

• Enhancing requirements with user stories, which evolved 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

Each experiment brought in new thinking, more alignment, and better momentum. One caution: don't follow any framework blindly without accounting for your team's culture and mindset. Rigid process adherence can look like the opposite of agility. We now blend concepts from several approaches to fit how our teams actually work.

5. Grow your PM capacity alongside development

As the development team grows, so does their throughput, and so does the demand on product management. That's straightforward in theory, but easy to underestimate in practice.

You need to grow PM capacity in step with development. The hardest part for me personally was letting go of the most exciting projects. I made a conscious choice to hand those to my team, because keeping them engaged and motivated mattered more than my own involvement in the work.

I also moved away from command-and-control as the team grew. What we needed instead was enough shared context for each person to make good decisions and move independently.

We grew from one Dev team, one PM, and one UX to four teams, each led by a Dev/PM/UX partnership. Each team runs its own version of design sprints combined with user story mapping.

6. Match product manager strengths to their projects

Every product manager job description covers the same ground: talk to customers, distill requirements, drive priorities. But the specific strengths that matter most vary by project, product, and company stage.

Beyond general PM skills, three background skill sets tend to stand out: UX and design, technical and development, and business. Most product managers have some ability in each area, but like any strengths profile, they'll lean toward one or two, rarely all three.

We were fortunate to have a strong UX team, so design skills weren't the primary factor when hiring PMs. But different areas of our product called for different emphases, business savvy in some cases, technical depth in others.

Over time, we occasionally shifted team members across focus areas. During one of those shifts, we had a mismatch: a PM with strong technical instincts was placed in an area where business acumen was the real driver. The PM made real progress, and the area advanced. But there was a cost to morale and team cohesion.

What made the difference was an open team culture. The PM raised it in a one-on-one, and we made another shift shortly after. That realignment had a significant impact on the PM's confidence and success within the company.

Those are the lessons we've learned. I hope you find them useful.