Why and how we follow project-based development

At crowd.dev, we are on a mission to make everyone on the team customer-obsessed. For an early-stage start-up, this is crucial as it decentralizes product decisions and helps prevent the founders from becoming bottlenecks for building and innovating. 

As our team and company grew, we noticed some areas of our development and product management process needed to be changed to support this mission. Specifically, we found our engineers were disconnected from our users, sprint goals were often unclear, and we needed more decentralized planning for features.

At WebSummit, we met Ferrucio from June, and he shared their project-based approach to development with us. We instantly saw the potential of this approach to bring our product team closer to users and empower them to make more decisions. We loved the idea and since have embraced a similar method at crowd.dev. 

So, what is project-based development?

Each new product feature is a standalone project in project-based development, with clear scoping, planning, and evaluation phases. Each active project (i.e. feature) has a designated project lead, who is responsible and accountable for the project from start to finish. 

The project lead plays a vital role, as they are responsible for scoping the project, creating a plan of action, managing resources and colleagues, and overseeing the implementation of the project. Project leads must ensure that all team members are informed and on track to complete the project. 

Additionally, they are in charge of evaluating the project’s success, which includes gathering customer feedback and usage data, analyzing the results, and determining what changes need to be made for future iterations. 

You can find our template for project planning here.

Think of a conductor guiding an orchestra or, from June’s blog, a surgeon leading his team.

“Much as a surgical team during surgery is led by one surgeon performing the most critical work while directing the team to assist with less critical parts, we have owners of projects develop critical system components while the rest of the team provides them with what is needed at the right time.”

‍

The meetings and cadence we follow

At crowd.dev, we now meet every Friday to discuss the progress of all open projects and plan which ones will be tackled the following week. During these meetings, project leads give updates on the status of their projects, and we discuss the priorities for the coming week. It is important that leads come to the meeting with a clear vision for the direction they want their projects to go. Maybe they only scoped the project and would like to start development with more team members. Or they already shipped an MVP and would like to pause their development for a week to get customer feedback and then iterate based on it.

‍

Roadmap prioritization and one-week cycles 

The horizon for a strict roadmap and prioritization is only one week. Each month we compile a flexible list of milestones to achieve, but these are only used as a soft guide. The needs of an early-stage product are constantly changing, and this allows us to stay as flexible as possible and to be able to focus on what the product actually needs at each point in time.

In our weekly meetings, we may pick one or two issues that should be turned into projects to be discussed in the meeting the next week. Then, a project lead is chosen who will be in charge of scoping the project by the following Thursday, giving everyone time to get familiar with the scope by the meeting on the following Friday. In this cycle planning meeting, we decide which scoped projects we will work on next week.

We also release every week. This helps keep the development process efficient, allowing us to make changes quickly based on customer feedback and usage data. This way, we can deliver features that our customers want and need and continuously improve crowd.dev. It also helps to keep us accountable for delivering value every week and keep our users engaged with regular, deterministic release content. Frequent releases are possible by splitting projects into sub-problems that each add value to the user, so we can divide our features into manageable chunks that we can roll out gradually.

‍

Why we chose this approach

We have found several benefits of embracing project-based development. We can better respond to customer needs, prioritize effectively, and deliver value quickly. The whole team is also much closer to the user. With the new process, each project has a clear plan, a dedicated project lead, and a focus on continuous evaluation. 

One of the main advantages is that it encourages your product team to think end-to-end, assess the impact of their work, and take on leadership roles. Rather than just ticking off tasks and building features assigned to them, it challenges everyone to think critically, prioritize, and take resources into consideration. Team empowerment is especially key in an early-stage start-up like crowd.dev where first-hires need to feel ownership and develop as the company keeps growing and evolving.

‍

A few things to consider

As with all things, project-based development is not a silver bullet. While we have found the approach has suited us, it requires work, and you should consider a few things before instating it with your team. 

First, project-based development requires that your team is willing and excited to stretch their responsibilities. It also requires team leaders to learn to let go and give a large part of their decision-making away to others. For the approach to lead you closer to customer obsession, you also need to give everyone access to your users and set up communication streams. For example, at crowd.dev, everyone is involved in user feedback calls and first-line customer support. 

If you have the right setup, you also need to think about the transition. Releasing every week and the big chunk of new responsibilities can be daunting for team members at first, so you must communicate and guide your team. 

‍

Looking ahead

We're excited to see the continued effect of project-based development over time, and we'll keep you updated on our progress. We look forward to your thoughts and feedback on the new process. 

If you have any questions about project-based development or want to share some thoughts, feel free to reach out via Email or Twitter, I’m always happy to chat.