High hopes and big ambitions meant there’s been a lot of work to do around here. Here’s how we’ve gone about getting it done.
Team update: A lot has happened since this blog - all great things! We’re now in the United States and our new product launched in November 2021, helping teams in fast-growing organisations find and hire their best-fit junior and mid-level talent in Sales, Marketing, Operations, and Customer Success. Try it here for free. This means some of our articles before this date may have product shots that look a little different. That’s all from us, enjoy the blog.
11 weeks ago, we set out on an ambitious plan to build the MVP of "Hatch 2.0". Over the past three years, we'd learnt a lot from operating the original Hatch model and had some big wins. We'd doubled the size of our team, adding a new lineup of functional capabilities. And we'd successfully spun-off an entirely different iteration of our product - the Hatch Exchange. So how best to go about building 2.0 warranted a rethink.
We've always worked with some form of a project system in place. It's naturally evolved as the team has. Knowing that we were going into a phase where we would be operating under high uncertainty with a relatively new team highlighted the need to create a common framework for how we should work together and hit our goals. Here's how we thought about using projects to achieve this - we hope you find it helpful.
What makes a project, a project?
For us, it's when we do significant, cross-functional work on new things that impact the core Hatch experience for any of our users. This is a relatively new way we’ve thought about the definition to encompass our new functional teams like Customer Success and Marketing.
Shape it till you make it
We've gone through periods where it wasn't always clear what the goals of the project were and what we should be working on. And we didn't like how that felt.
That’s why this time around we’ve pushed shaping as a vital step before starting a project. Shaping is the process where we turn an idea into a well-defined and understood piece of work that can be executed by the project team. By shaping the project upfront, things go much more smoothly when it’s time to execute.
We've had a few false starts to projects when we haven't been thorough enough with our shaping. While a level of abstraction is great for the team to creatively explore how to tackle the problem, if they don't know what to do or where to start, it's an easy tell that more shaping is required.
So what did we learn about how to shape a project well?
Start with the problem
It sounds trivial, but be clear on what problem you're trying to solve. If you assume it's clear, everyone will come at it with their own definition. Seek alignment and provide clarity on this early.
What's our appetite?
We used to think about how much time it will take to complete a project. Now we check our appetite for a project upfront by asking how much time we want to spend on it. This ensures that we limit the downside of spending too much time on a project where it wasn’t warranted. Instead, it forces us to focus on the most important elements of our solution.
Here's a rough solution
We come up with a high-level solution that helps us understand how the pieces fit into the bigger picture. It also allows individuals to understand their contribution, as well as identify any rabbit holes we’ll need to avoid, if we’re to stick to our appetite.
Good looks like...
Imagine the end goal! What will success look like and how do we want to track that?
Documentation's role
We've encountered the diminishing returns of over-documentation. One example of this was when we kicked-off this round of projects, we had the intention of updating a WIP document daily. But it didn't end up getting done as it didn't fit the rhythm of how we were working. And let's be real - not every document gets read.
We reflected on the role of documentation and two things became clear:
We should use documentation as a tool for aiding how we think.
When using documents as a comms tool, you can't just put your thoughts on paper and hand it over. Thinking about what context is needed and what format makes the most sense for what you need to communicate is valuable. Connecting people with the right information takes time and effort but is an investment, not a tax.
Pressing pause
We knew it was unlikely we’d get the project system right from the start, so we created some checkpoints to review how it was working for the team. This is important because if your team is anything like ours, the type of work you’re doing will evolve over time and so should your ways of working. We used retros as a way of doing this. Some examples of things that came up in our most recent retro:
The project system was helping us bucket work logically and know the boundaries of that work.
But we found that there are types of work that aren’t well-served by the project system, so we decided to treat them separately.
Heartbeats (inspired by Basecamp) were a winner. They're the sweet-spot for project updates and a simple way for Project Leaders to keep the team up to speed on what everyone's working on.
Speaking of "Project Leaders" - we weren't all clear about what their role was. We now think of that role as the "shepherd" of the project. They guide everyone in the right direction of the work that needs to be done but aren't necessarily responsible for doing all of it.
Small, tactical projects are OK so long as the overheard of coordinating between them doesn't outweigh the benefit of consolidating them into one, larger piece of work. If there are lots of interdependencies between projects, grouping them together makes more sense.
Heartbeats: short & simple!
How did we do?
We've taken big strides with the projects we completed recently. We launched early-access to our MVP ahead of schedule. This has given us a headstart on testing how it operates and how our Product, Marketing, Customer Success and Operations teams can come together to create an amazing experience for our customers.
As we’re now standing on the (somewhat) solid ground of our MVP, the work we’ll do next is going to look and feel a lot different. Our MVP reflects our current thinking about how we want to solve some of our customer’s biggest problems. Now that we’re ready for them to use it, we’ll start to gather data to test our assumptions about what people do, instead of what they say. We expect our work to look less theoretical and way more practical for the remainder of the year.
Regardless of what shape it takes, we’ll continue to iterate on how we work together at Hatch to build great products for our customers and have a lot of fun while we do it!
Looking for inspo for how to run your projects?
Here's where we found it:
Basecamp, full stop. But in particular their book ShapeUp. Ryan Singer, their Head of Strategy, also shares some great stuff on his Twitter and Podcast.
Silicon Valley Product Group have a great blog, and their book INSPIRED.
