Agile vs. Burndown Software Development

Matt Bilotti has a great post titled How We Build Products at Drift. The crux of the article is that there’s a new, and better, way to do software development: burndown. Today, in the startup world, agile is the most common software development methodology. Only, it’s centered around the two week sprint, and the reality is that the customer feedback loop is much faster than two weeks.

Here’s the breakdown on agile vs. burndown from the post:

  • Measure of success
    • Agile – Thoroughness of story, agile points and velocity
    • Burndown – End user feature adoption & retention
  • Means of determining prioritization
    • Agile – Product backlogs and sprint planning
    • Burndown – End user validated design mockups and prototypes.
  • Speed
    • Agile – Story-based sprints (weeks)
    • Burndown – Micro-sprints (days)
  • Release focus
    • Agile – Multiple features grouped into a single release version
    • Burndown – A single version of a single feature per release
  • Flexibility
    • Agile – 2-week sprints are planned, executed & generally inflexible once agreed upon
    • Burndown – Every day priorities change and so do the current and upcoming sprints

Feel like the agile software development methodology isn’t quite right for your team? Consider trying out some of these burndown concepts.

What else? What are some more thoughts on agile vs. burndown methodologies?

Simple Product Management Planning Process

Scaling the product management planning process is a real challenge as the startup goes from idea stage to early stage to growth stage. At first, the entrepreneur guides all product functions. Then, there are too many different pieces and a product management group convenes on a regular basis to plan and curate functionality. Finally, product management becomes it’s own team (initially a team of one) and grows from there. Naturally, more process is required as the company grows.

Here’s an example product management planning process:

  • Create a simple Google Spreadsheet with sheets for different constituencies
  • Solicit requests from sales, marketing, services, support, client advocates, product management, and engineering in individual sheets
  • Review the customer idea exchange and take the top 10 most popular items and 20 other items that have the most bang-for-the-buck and add them to a new sheet
  • Analyze trends from the 100 most recent support tickets and confirm the big ones are in the Google Spreadsheet
  • Categorize every item based on priority (low, medium, high) and difficulty (low, medium, high)
  • Get a group of stakeholders together, no more than five people, and debate everything that’s been assembled and decide on the items for the next quarter
  • Share the quarterly roadmap with the team and ensure alignment
  • Repeat each quarter

Start with a simple product management process and expand it from there always considering the balance between moving fast and making the best decisions possible.

What else? What are some more thoughts on a simple product management planning process?

No Product Roadmaps

Continuing with yesterday’s post on Quarterly Product Themes, another area we struggled with at Pardot was product roadmaps. Early on, we tried to map things out for the product. We’d come up with an idea to do Z, and in order to Z we first needed Y, and everything was laid out beautifully. Then, a week later, this other idea/request would come up, we’d debate it vigorously and decide it was more important than an item on the roadmap. Staying close to the customer required a short feedback loop and necessitated rapid product iteration.

It was time for a change. It was time for no product roadmaps.

Instead, we had a Google Sheet with a separate tab for each department in the company and their product requests along with a GetSatisfaction idea board for customer requests. Finally, there was a Google Sheet tab for the priority product items and that constantly changed as we moved requests in and out as well as implemented new features and fixes. When a prospect or customer would ask about our product roadmap, we’d say we don’t have a detailed roadmap due to the need to stay nimble, but we’d share big broad ideas about our general strategy and product direction. The product roadmap was no more.

What else? What are some more thoughts on not doing product roadmaps?

Quarterly Product Themes

One of the challenges we had at Pardot was balancing the different requests from our constituents. Sales wanted one set of features while customer success wanted a different set of features. Then, support had their own desires separate from engineering which wanted to make a number of behind-the-scenes improvements. What to do?

We eventually arrived at doing a product theme every quarter where we alternated between heavy market-facing improvements (lots of shiny bells and whistles for sales) and heavy back-end improvements (lots of infrastructure work, fixing of nagging issues, and general product polishing). This process worked well in that it was clear to our different stakeholders where the emphasis was for the quarter, along with the expectation of what we’d do the following quarter.

Consider using product themes for each quarter as the startup grows and product demands increase.

What else? What are some more thoughts on quarterly product themes?

Make Company Name and Product Name the Same

At Pardot, we originally named our product Prospect Insight, thinking we were cool with a product that was abbreviated PI (Note: You can still go to prospectinsight.com and it redirects to Pardot). Only, at the time, we didn’t understand that it was a bad idea to have a product name separate from the company name. As we started to gain traction, customers would refer to the product as Pardot, and not Prospect Insight. Eventually, we realized that to our customers the product was one and the same as the company, and we dropped the product name Prospect Insight.

The company name and product name should be the same. It’s hard enough to build one new brand, let alone two simultaneously. Make things easy and simple: keep the names the same.

What else? What are some more thoughts on making the company name and product name the same?

Going Deep or Broad with the Product

One of the product questions entrepreneurs need to ask themselves early on is if they’re going to go deep or broad with the application. In general, as customers ask for new features, they have a tendency to be broader requests (e.g. can you add adjacent feature XYZ?). Keep in mind the importance of product focus, especially the part about being opinionated.

Here are a few questions to ask when considering going deep or broad:

  • Is this product a point solution or a platform (everyone wants to be a platform but point solutions are much more common)?
  • Does this feature request strengthen an existing feature or does it introduce a new concept?
  • Are customers asking for more product depth or more product breadth, generally?
  • Does the product roadmap reflect more depth or breadth? Is that direction intentional?
  • How does depth and breadth reflect reflect the current customer base vs the desired customer base (e.g. entrepreneurs often want to expand upmarket over time)?

Entrepreneurs would do well to think through their product strategy when it comes to going deep or broad with the application. Deep is the more common successful route.

What else? What are some more thoughts on going deep or broad with the product?

Platforms and Microservices

Steve Yegge has an epic rant on Amazon being a poor place to work but more brilliant than Google when it comes to innovation at platform scale from 2011. David Skok recently published a post on his blog titled Microservices Essentials for Executives: The Key to High Velocity Software Development. The idea is that tech companies start out building their product as one large, monolithic system because it’s simpler and faster. Then, as the startup achieves greater levels of success, innovation slows down considerably even though more and more people are added to the product team. What gives?

The larger the product, the harder it is to make changes to it due to all the dependencies. Amazon was the first major technology company to realize that Internet scale, and it’s greater levels of complexity, requires a new way of building large-scale systems: microservices. Microservices are simply smaller, self-sufficient special purpose products that form a platform (e.g. tiny apps that are used to make a big app). Amazon went further and built Amazon Web Services (AWS) to make the backend of these microservices even easier to manage and scale, and now AWS is one of the fastest products to $10 billion in annual revenue, ever.

Tech entrepreneurs need to understand the benefits of microservices and start planning them once they hit the growth stage, but not before. All major platforms going forward are going to have some form of microservices underpinning them.

What else? What are some more thoughts on platforms and microservices?