I asked 100 developers & PMs how they build software. Here’s the results.

--

I recently ran a survey, asking people how they and their teams build software. I’ve compiled a summary of the results below.

But first, I’d like to say a huge thanks to everyone who took the time to complete it!

Why I did this

I’m currently building Shaped: a lightweight product development planner and tracker for startups & small teams. I wanted to learn a little more about how teams approach software development today and where they are facing challenges.

The results

Who completed the survey?

The survey was completed by just shy of 100 people.

Most work in larger companies of more than 100 employees (which is not my target market, but there is some interesting data nonetheless).

I took the opportunity to find out where teams are working and was a little surprised to discover the majority are still working remotely or hybridity (is that a word?). I had assumed that larger companies, at least, had started to head back into the office.

A question I wished I had asked was: where in the world the company was located. It would have been interesting to see if there was any correlation between that and remote/hybrid/office work.

Anyway, we now we have an idea of who these teams are. Onto the meat of the survey: how teams plan and develop software.

Development planning process

When it comes to planning what will be worked on by the development teams, most companies are using feature roadmaps. And it’s not just the big companies doing this — you can see a fairly even spread amongst all company sizes.

Feature roadmaps are the most popular technique. They can be seen as a little old-fashioned in this day and age. But leaders and stakeholders have a hard time letting them go, as it gives them a sense of clarity and control. The biggest flaw with ‘feature roadmaps’ is that they assume that the feature being planned is the right feature to build. They lock teams into building solutions that aren’t going to work and that leads to wasted effort.

Theme/outcome-based roadmaps came in fourth. This is similar planning technique to feature roadmaps but instead of planning “features to build” the business will plan “outcomes to achieve”. This subtle shift means that development teams are not being committed to specific features, but outcomes to hit. And the ownership moves to the teams to discover and build the right solutions.

The concept of outcome-based roadmaps are not disimilar to OKRs, which is the same fundamental idea, but with more structure.

When it comes to startups, I typically advise that Now/Next/Later is a good framework for planning. Startups are typically changing direction a lot, as they learn new things and discover new opportunities. So restricting planning to what is happening Now, what are they going to do Next, and what things they might do Later is a helpful way to focus their limited resources.

Most companies plan ahead in quarters. This is a sensible time frame that gives teams time to get stuck into chunky problems and deliver meaningful outcomes.

I am a little concerned about the one company that plans ahead for the next 5 years though!

In terms of satisfaction with their planning, it’s fairly evenly spread over the different company sizes. Though companies with 2–10 employees seem to have the advantage. At this stage of a company’s life, planning tends to be a simpler affair.

There was no particular correlation between satisfaction and planning technique or how far ahead the planning was done.

Software development process

When it comes to the development process teams use, Scrum is by far, the most popular methodology.

“Mixture” comes next, which is where teams are use a mix of different techniques for their specific needs.

Interestingly, the third most popular process was not to have a process at all. I can’t see how that work for larger companies!

Shape Up is a relatively new methodology that comes from the team behind Basecamp. It’s a process that I’m excited about and I think works very well for startup teams. (Indeed, my product Shaped supports Shape Up out of the box).

No real surprise here, most teams work in 2-week cycles.

Development tracking tools

Jira is the software everyone loves to hate, but they all use it anyway! With Trello coming in fourth, it’s fair to say Atlassian have cornered a very good chunk of the market.

What was more surprising was how many people use spreadsheets. I should note, however, that people were able to select multiple answers for this question. So this is not saying that some teams use spreadsheets as their sole software tool for planning and tracking.

So there you have it, a snapshot of 100 or so companies and how they are currently developing software. I hope you found it interesting and/or useful. Let me know in the comments.

About me: I’m James!

I’m a startup and product coach with previous experience working in product, operations & engineering at various companies and startups.

I realised that the current tools for planning & tracking product development are just too heavy and that’s why I’m building Shaped: a super-lightweight project management tool for startups.

Click the link to sign up for early access 👆

--

--