#356 – Small Even Over Big

#356 – Small Even Over Big

This week, we reflected on the impact of taking many small steps, rather than a few big ones.

As excited, ambitious makers, it’s very tempting to shoot for the moon – set a big vision, build the perfect thing, and send your fully-formed, complete idea out into the world when you’re really proud of it. The challenge is that this is slow and risky:

  • It takes a really long time to get something you’re truly proud of, especially when you have high standards and?taste
  • Since it takes a long time, you better be right – because you’ve invested a lot into it

As we’re rounding off?another strategic planning cycle, we’ve been surprised and delighted to see how going against this instinct has served us, and we’re setting an intention to do it even more.

The example that’s been going around the metaphorical halls is around our work on self-serve conversion, which we prioritized two cycles ago. As part of this work, we’ve tested three limits on our Starter plan: the number of teams, the number of built-in templates, and how much history teams can access.

The first two – team and template limits – were complex and risk, so we took our time. The last one – meeting history – was relatively simple to built and low risk, so it was much smaller to implement and quicker to test.

We recently took a look at which limitations were most effective in getting folks to upgrade, and we found a surprising answer:

No alt text provided for this image

Even though the other two limits converted better, because Meeting History was smaller to build and quicker to test, it was validated and rolled out much earlier. This relatively small limit drove an overall bigger impact because it was out so much longer, showing the value of making a small change fast versus a larger change slower.

We’ve added a few practices into our rituals to put this to practice:


  • As our squad shifted our mission this strategic cycle, we started by prioritizing any low-hanging, quick-win changes, which is where?this improvement?to our?new team?flow came from (identified & shipped in less than a week!).
  • In our weekly check-ins, we’re reviewing our priority epics and asking if scope has changed, then deciding if those additions are truly needed or if we should make a different choice.
  • In our?Sprint Poker meeting?to estimate effort & risk for larger features we may take on, we added a dimension for?Can this be smaller??with a scale of Yes or No. If anyone voted Yes, we discussed their idea, and how we might scope the feature down. As Squad Product Manager, I then edited the epics on our backlog to reflect this smaller scope.

Like all teams, we’re always looking to go faster, but for this next cycle, we’re taking the words of our colleague Marcus Wermuth , Head of Product Development, as a new mantra:

Not faster – must go smaller.

In case you’re curious, we wrote about?the value of even over statements for setting strategy here.

Metrics

No alt text provided for this image

While we anticipate an overall slowdown during these summer months, we saw a significant increase in Sprint Poker meetings this week.


This week we…

…Published a?product-led guide on running post-mortem meetings

…Ran our user Feedback Monthly Retro.

…Squads and teams worked on aligning the company strategy to specific team goals.


Next week we’ll

…wrap up our planning.


This week's Friday Ship was written by Parabol's Head of Growth,? Aviva Pinchas

For past editions of the Friday Ship, check out our?blog.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了