Ever feel like your product team is not working to its full potential? Here at Carbon Five, we’ve worked with hundreds of product teams, and we wondered what differentiated strong teams from struggling teams.
Our curiosity drove us to create the Product Dartboard, a digital tool that helps teams identify their strengths, challenges, and blind spots, and provides teams with actionable steps to continuously improve.
Speaking of continuous improvement — we just released a few updates to the Dartboard. Now you can see a more detailed Dartboard report, facilitate a productive team discussion with our downloadable guide, and create your own follow-up assessments — which is critical to team success! Continue reading …
We were honored to receive the award for Outstanding Product Agency in Amplitude’s Emerging Product Leaders Awards.
This award is for the agency that provides clients the best product development, growth, or strategy support. At Carbon Five, product managers help clients to transform their vision into reality. We also build high-performing teams, mentoring client PMs and leaders so that they can continue to build amazing things once we roll off the project. Continue reading …
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 …
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 …
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 …
At Carbon Five, we build software. We build it using Agile methods. This has worked out well for us and our clients for a long time. We recently added product management as a discipline to our team. There are some common challenges we see at C5 and we’ve been deliberately experimenting with different activities and practices around product development, some of which we will be sharing in this series of blog posts.
Our team is working in a startup environment. Our product owner–let’s call him Alex–while business savvy, has no product management experience. He has a very clear and detailed vision of the product in its finished state. Complete with comps. Those designs, while beautiful, were not created in response to specific user problems; they’re a product of Alex’s brain alone. When our team begins work, questions arise. User stories are written against the comps, instead of against problem statements generated by research with real users. The comps are referenced, but a picture doesn’t necessarily speak the same 1000 words to everybody.
Continue reading …