We <3 Prioritizing

In modern software processes, prioritization is at the core of what we do.

We prioritize because we don’t like waste. Waste:

• Of human effort, which is disrespectful.
• Of money.
• Of time.

If you’re wasting one of them, you’re probably wasting all of them.

Prioritizing is variously simple, complicated, demanding, exhausting, and strangely emotional.

In this series, we introduce some tools that can help you successfully navigate prioritization on your product, at every level and every phase of product definition and development. Continue reading …

In a discussion about prioritization among product managers at C5, we were in consensus that a 2×2 is a powerful tool in many prioritization scenarios from assessing risks to the product or business to working out the path forward when faced with competing priorities for a product.

As a visualization tool, a 2×2 gets the team on the same page to externalize relative risks or priorities and work through next steps. When things seem murky or like everyone isn’t giving the same weight to particular options, try out a 2×2. Continue reading …

I asked a group of fellow product managers if they’ve ever read through the Agile Manifesto with product owners / clients. They all said “no”, and the general consensus was that doing so wouldn’t be well received. This is interesting. Even though Carbon Five is well-respected for our process, and we definitely practice agile, we’re guarded about discussing it. Continue reading …

We just received our copies of O’Reilly’s latest Product Management title, Product Management in Practice: A Real-World Guide to the Key Connective Role of the 21st Century, by Matt LeMay.
Continue reading …

Carbon Five was recently brought in to build a new product with a planned budget of 6 months. As the first step, we conducted a few rounds of customer development to try and validate the concept. After a month of experiments by a product manager and designer, we ultimately recommended that the company not pursue the idea. Our client spent a few weeks of consulting fees but saved more than 90% of their budget by not building anything.

The client for this project provides software to a niche set of businesses. As more and more competition started popping up, they believed they saw an opportunity to create a digital marketplace in their niche. Before Carbon Five started building software, the client wanted us to confirm demand for the marketplace.

Continue reading …

The tech scene (especially in the Bay Area) has reached a point where it’s expanded way past techies. It seems successful people from all different industries are drawn to the promise, reach, and money in tech. Doctors, bankers, artists, and even educators are launching startups and talking about MVPs. It’s definitely exciting and inspires me everyday. But, building a great product is sometimes more of an art than a science, and first time founders make common mistakes. From a company that has worked with more startups than it can count, and has seen its fair share of first time product mistakes, here are some of the most common ones to avoid.

Continue reading …

As a full-stack software consultancy, we at Carbon Five get lots of questions from clients past, present, and future. We’re passionate about sharing our industry knowledge, so we sat down with our leadership team and got some advice for aspiring founders and product leaders as part of an ongoing 6-part series. You can see all the interviews here.

How healthy is my codebase? Can I rewrite it, or can it be nursed back to health?

A hundred percent of the time, your codebase can be nursed back to health. In my experience, ninety-five percent of the time, that’s the path you should take. This is making one assumption, that there’s a product already built and in use. The bigger the codebase, and the longer it’s lived, the more likely that it has features or bugs or whatever, pieces of code that are in use, that people are relying on, but nobody knows about at the company. So whenever you talk about rewriting a codebase to be the same as an existing codebase, you are opening yourself up for a world of pain because it’s very likely that there’s nobody in the world that exists who knows all of the requirements. If you ever decide to rewrite a codebase, you have to start from first principles and say, “We have to start from the very beginning and define what this new product does, and as a basis, we’re going to use this old product, and we’re going to say this is our starting point.” The same way if a client came to us with wire frames and said, “This is what I want,” we’d say, “Well, we’re going to use this as a starting point, but we’re still going to go through our personas exercise, and our experience map, and our story mapping, and our story writing, because we need to understand all that in order to build this product.” If you can do it that way, then rewriting is actually completely doable. I’ve discovered that even though it can be a lot of work to nurse a codebase back to health, if the functionality is there and fulfilling the needs of the users, then to continue to fulfill the need of the users without any interruption, you gotta nurse it back to health.

A hundred percent of the time, your codebase can be nursed back to health. In my experience, ninety-five percent of the time, that’s the path you should take. This is making one assumption, that there’s a product already built and in use.

Continue reading …

Have you ever worked on a team that went off the rails? Product teams need lots of support to run efficiently. You need to move fast, but you also need to be aligned in order to build successful products. Here are a few activities we use to keep our teams moving. We often facilitate them in Stickies.io, a product we built for collaboration, but any of these activities could also be done using analog sticky notes.

When you need to generate ideas

Rapid Rounds

We like to structure brainstorming sessions to help get the entire team working together towards a unified goal. We set a timer for 3-5 minutes to challenge ourselves to think fast and broad. Then, we review the ideas and do another rapid round, with 2-4 minutes this time. Finally, we give all team members 3 votes and prioritize our ideas based on votes. The sequence looks like this:

• Introduce the goal of the brainstorming session
• Run rapid rounds.You can run as many as needed. We typically reduce the time set as we go and build off of each other’s ideas.
  • Set the timer for 3-5 minutes
  • Individually ideate on post-its until the timer goes off
  • Let everyone describe their top 3 ideas
• Give everyone 3 dots and ask them to vote on three ideas to explore further
• Arrange ideas by votes

In person, we use post-its, sharpies and sticker dots:

Continue reading …

As a full-service software consultancy, we at Carbon Five get lots of questions from clients past, present, and future. We’re passionate about sharing our industry knowledge, so we sat down with our leadership team and got some advice for aspiring founders and product leaders as part of an ongoing 6-part series. You can see all the interviews here.

First up are some practical answers from Partner and COO Don Thompson on lessons learned from 15+ years of collaboration on client-driven technical projects and insights into how Carbon Five’s process enables companies of all sizes.

When do I build my internal team?

Beginning day one is our preference. The happiest clients are the ones that have a team in place to take over before we’re done. It doesn’t have to be a CTO–that can simply be a junior developer. It can be a struggle for clients to make a junior hire if they have more confidence putting a senior person in place. They feel a Director or VP will have more confidence in some of the decisions they’re making early on, and can build out their own team. From our standpoint, either approach can be successful.

Where do I find my talent, and how do I attract them?

That is really tough. The early hires will often establish and shape a corporate culture so it is important to get it right. In addition to the roles to hire for, we encourage our clients to consider making diversity a hiring goal. Creating a balanced, inclusive team takes more time and effort than most company founders expect. When our clients do begin to ramp up hiring, we’re happy to help with writing a job rec and shaping a job description. We’re happy to help review resumes. We’re happy to interview people and really be that advocate for our client as far as where people can fit into the organization. We’re happy to give them desk space once they’re hired. We have a recruiter, and we’re happy to make introductions to on the behalf of our client.  While we still encourage people to reach out to their own networks, remember to reach out well beyond it.

In addition to the roles to hire for, we encourage our clients to consider making diversity a hiring goal. Creating a balanced, inclusive team takes more time and effort than most company founders expect…while we still encourage people to reach out to their own networks, remember to reach out well beyond it.

Continue reading …

Update: Product Dartboard is now digital. Create your Dartboard account here!

Some projects go so well you want to bottle them. Others, not so much. A few months ago, I started surveying our projects from the last three years. I was looking for patterns of success and … less success. I had heard people say that there wasn’t much of a correlation between projects that were successful for Carbon Five and products that were successful in the marketplace. That felt simultaneously plausible (lots of products fail, but that doesn’t mean it was a horrible project) and unlikely (it doesn’t make us happy to work on things that don’t succeed). I asked C5ers to grade projects based on how well the project went. Then I recorded whether the product had been a success (as defined by the client). It turned out that there was actually a pretty strong correlation between projects we graded higher (A or B) and products that had succeeded. And projects where the C5 team was dissatisfied often resulted in unsuccessful products.

Once I saw this, I wondered: how might we increase the likelihood of success? Is there some way we could predict successful outcomes and try to make all our projects look more like the great ones? We’d have more fun and our clients would enjoy more success, in theory. But was it possible? Continue reading …