Often you hear product teams talking about their roadmap in investor-like terms. Managing their upcoming initiatives like a financial portfolio, distributing their bets among things of various categories, sizes, and risks — like a portfolio manager would do to hedge risk. Umang Jaipuriamakes the case that product teams should be inverting this logic: concentrating their bets (and therefore, money and energy) behind fewer things.
All product teams should have ONE bet they are making, and put all their effort into making that successful. The fact of the matter...
Sam Gerstenzang wrote an excellent piece a couple weeks ago with operating lessons for growing companies, driven by his learnings from the product team at Stripe. Personally, I’ve got a decade or so of experience as an “operator” at a “startup” (two words I wouldn’t have used to describe my job during most of that time). Since 2011 I’ve led the product team at Fulcrum, a very small team until the last few years, and still only in the medium size range. So...
With Shape Up, the process of “shaping” new product takes investment to really understand and communicate an idea. But in the process, this precedes the “pitch”, the step where the team reviews a shaped concept and buys into working on it:
According to the book, shapers prepare pitches, pitches go to the betting table, and then the business decides at the last moment which pitches to “bet on.” Teams who follow this to the letter encounter a problem: how do you justify spending the time to shape something when you don’t know if the business will...
I linked a couple weeks ago to a piece from Marty Cagan. That led me to this talk that covers a lot of his thoughts on approaching product issues. Wide ranging and thought provoking stuff for product managers.
If you’re in any line of product management or product development, you’ll be familiar with the argumentation process around defining the product launch. The concept of a “pre-announcement” is something as old as the job of product marketing, with all forms of the process being tried by companies over the years. You have the Apple-like “no announcement til launch day” approach on one extreme, and the “announced before any of it exists” vaporware announcements of which there are hundreds of examples.
I started with the first post in this series back in January, describing my own entrance into product development and management.
When I joined the company we were in the very early stages of building a data collection tool, primarily for internal use to improve speed and efficiency on data project work. That product was called Geodexy, and the model was similar to Fulcrum in concept, but in execution and tech stack, everything was completely different. A few years back, Tony wrote up a retrospective post detailing out the...
This is a brief series for those interested in getting into product management, in four parts. This first post is about how I got into this line of work and the beliefs I’ve formed over the years on the discipline. Enjoy!
I never set out of college to get into product development. I was a geography guy with a penchant for maps and wanted to learn how to make them. I bounced from an engineering major over to geography early in school because I was passionate about it, with no clue what the ultimate career destination might look like. After...
The vast majority of features won’t bend the curve. These metrics are terrible, and the Next Feature Fallacy strikes because it’s easy to build new features that don’t target the important parts.
This certainly rings true for me from experience over the years. It turns out that a single feature itself is far from the main problem halting people part way into on-boarding with a product. This falls into the category of focusing on what we know how to do already, rather than what’s important to do. What’s...
In product teams you’re continually faced with the challenge of scoping. When you build something directly for a customer, for a fee (consulting), the scoping process is explicit and has built-in constraints — customer expectations, funding, timelines, deliverables. Even in that scenario, agreeing on a firm scope for an effort isn’t simple, but it’s even harder when working in a product company. The same constraints still exist, but in a more nebulous, undefined form. Constraints aren’t imposed and enforced externally by a single client dangling the paycheck. The demands are dispersed amongst thousands of users with sometimes-competing desires, paying varying...
A continuous challenge in product development (perhaps the ultimate challenge) is the balancing of many wants and needs with an inability to have everything. You never have the resources to build everything you want into your product — be it labor, capital, or time.
All this year I’ve been studying economics, some foundational resources, different philosophies, and the history of economic theories. I think what attracts me to the subject is how its fundamentals can be applied to so many other areas. I just finished Thomas Sowell’s Basic Economics a few weeks ago, which is a great...
Fulcrum, our SaaS product for field data collection, is coming up on its 7th birthday this year. We’ve come a long way: from a bootstrapped, barely-functional system at launch in 2011 to a platform with over 1,800 customers, healthy revenue, and a growing team expanding it to ever larger clients around the world. I thought I’d step back and recall its origins from a product management perspective.
We created Fulcrum to address a need we had in our business, and quickly realized its application to dozens of other markets with a slightly different color of the...