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 …
Request Access to Product Dartboard Private Beta
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 …