With product design, constraints are your friend. Great products emerge from teams able to differentiate between control and noise factors: things they can control vs. things they can’t. Many teams are tempted to waste time worrying about things outside of their control.
In this example, the control factors are all the things we get to decide: Which quotes to include, whether the block has some header text or not, the language of the header text, the position of the name of each reviewer relative to their quote, whether to use just first name...
In product development, you can orient a team toward process or practice. Process is about repeatability, scalability, efficiency, execution. Practice is about creativity, inventiveness, searching for solutions.
Choosing between them isn’t purely zero-sum (like more practice = worse process), but there’s a natural tension between the two. And as with most ideas, the right approach varies depending on your product, your stage, your team, your timing. In general, you’re looking for a balance.
I heard about this concept on a recent episode of the Circuit...
“I would not give a fig for the simplicity on this side of complexity, but I would give my life for the simplicity on the other side of complexity.”
What a great line from Oliver Wendell Holmes.
When you think you’re coming up with “simple” responses to complex problems, make sure you’re not (as Bob Moesta says) creating “simplicity on the wrong side of the complexity.”
What we really want is to work through all the tangled complexity ourselves as we’re picking apart the problem and designing well-fit solutions.
This is an interesting look into how an effective team works through the weeds of a product design review. I love how it shows the warts and complexities of even seemingly-simple flow of sending a batch email in an email client. So many little forking paths and specific details need direct thinking to shape a product that works well.
Building new things is an expensive, arduous, and long path, so product builders are always hunting for means to validate new ideas. Chasing ghosts is costly and deadly.
The “data-driven” culture we now live in discourages making bets from the gut. “I have a hunch” isn’t good enough. We need to hold focus groups, do market research, and validate our bets before we make them. You need to come bearing data, learnings, and business cases before allowing your dev team to get started on new features.
Reading Ryan Singer’s Shape Up a few years ago was formative (or re-formative, or something) in my thinking on how product development can and should work. After that it was a rabbit hole on jobs-to-be-done, Bob Moesta’s Demand-Side Sales, demand thinking, and more.
Since he wrote the book in 2019, he talks about 2 new concepts that extend Shape Up a little further: the role of the “technical shaper”...
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...
Have you had that feeling of being several weeks into a project, and you find yourself wandering around, struggling to wrangle the scope back to what you thought it was when you started?
It’s an easy trap to fall into. It’s why I’m always thinking about ways to make targets smaller (or closer, if you’re thinking about real physical targets). The bigger and more ambitious you want to be with an objective, the more confidence you need to have that the objective is the right one. What happens often is we decide a project scope — a feature or product...
Product-led growth has been booming in the B2B software universe, becoming the fashionable way to approach go-to-market in SaaS. I’m a believer in the philosophy, as we’ve seen companies grow to immense scales and valuations off of the economic efficiencies of this approach powered by better and better technology. People point to companies like Atlassian, Slack, or Figma as examples that grew enormously through pure self-service, freemium models. You hear a lot of “they got to $NN million in revenue with no salespeople.”
This binary mental model of either product-led or sales-led leads to a false dichotomy,...
Ryan Singer shows his work through the process of shaping a new feature for a product he’s building. This is a great detailed example of a process following the Shape Up philosophy.
Looking over the virtual shoulder of someone’s process as they think through a problem from abstract → concrete is incredibly helpful at sparking ideas to help unstick my own projects. I like the nonlinearity here in his procedure. It doesn’t go unidirectionally from coarse to fine; along the way he’s using lower- or...
“Efficiency is doing things right; effectiveness is doing the right things.”
— Peter Drucker
People throw around these two words pretty indiscriminately in business, usually not making a distinction between them. They’re treated as interchangeable synonyms for broadly being “good” at something.
We can think about effectiveness and efficiency as two dimensions on a grid, often (but not always) in competition with one another. More focus on one means less on the other.
That Drucker quote is a pretty solid one-line distinction. But like many quotes, it’s concerned with being pithy and memorable, but not that helpful.
I linked a few days ago to Packy McCormick’s piece Excel Never Dies, which went deep on Microsoft Excel, the springboard for a thousand internet businesses over the last 30 years. “Low-code” techniques in software have become ubiquitous at this point, and Excel was the proto-low-code environment — one of the first that stepped toward empowering regular people to create their own software. In the mid-80s, if you wanted to make your own software tools, you were in C, BASIC, or Pascal. Excel and its...
If you’re on the internet and haven’t been living under a rock for the last few months, you’ve heard about the startup Clubhouse and its explosive growth. It launched around the time COVID lockdowns started last year, and has been booming in popularity even with (maybe in-part due to?) an invitation gate and waitlist to get access.
The core product idea centers around “drop-in” audio conversations. Anyone can spin up a room accessible to the public, others can drop in and out, and, importantly, there’s a sort of peer-to-peer model on contributing that differentiates it from podcasting, its closest analog.
In the wake of Salesforce’s acquisition of Slack, there’s been a flood of analysis on whether it was a sign of Slack’s success or failure to grow as a company. It’s funny that we live in a time when a $27bn acquisition of a 7-year-old company gets interpreted as a failure. I’d consider it validation for their business that a $200bn company like Salesforce makes their largest acquisition ever on you. Broadly, it’s a move to make Salesforce more competitive with Microsoft as an operating system for business productivity writ-large.
This week Stripe launched two new major products in their ever-expanding mission to build the economic and financial backbone for the internet.
Ben Thompson was one of two (along with the Wall Street Journal) to have embargoed early access to their launch of Stripe Treasury, their latest major product category. This interview with Stripe co-founder John Collison dives into the background on the product launches, Stripe’s strategy, and where these fit into the wider Stripe mission.
They’re extending their Capital product, which originally launched in 2019 to give Stripe customers access to capital for...
I just finished publishing my summary and takeaways from Marty Cagan’s Inspired, his collection of ideas on building product teams. A lot of solid fundamentals there for startups, more meat on the bone in this one than most business books of its ilk.
I’m gradually working back through book highlights and building out literature notes, which I’d also one day like to get published in full somehow. I’m thinking about how I can do that while preserving some of the interlinking in my Roam graph, and publishing some of those evergreen notes, as well.
An option is something you can do but don’t have to do. All our product ideas are exactly that: options we may exercise in some future cycle—or never.
Without a roadmap, without a stated plan, we can completely change course without paying a penalty. We don’t set any expectations internally or externally that these things are actually going to happen.
I know Basecamp is always the industry outlier with these things, but the thoughts on roadmaps are probably more true for many companies in reality than we’d all like...
I recently watched this Mark Roberge session where he had an interesting way of describing the challenge that follows product-market fit. Tons of startup literature is out there talking about p-m fit. And likewise there’s plenty out there about scaling, leadership, and company-building.
One of the most fascinating stages is in between, what he calls “go-to-market fit.” This is where you’ve found some traction and solved a problem, but haven’t figured out how to do it efficiently. Here’s how you think about the...
Basecamp’s Ryan Singer has been doing this solo podcast on a lot of his favored topics, centered around product design. But he also branches into adjacent, related areas of systems, research, user experiences, and more.
I like the solo format as a different approach to your standard conversation or interview shows. I’ve listened to a couple of these, and the best way to describe the content is somewhere between a Twitter thread and a blog post series. You get the good parts about the Twitter medium — the sort of unstructured, “thinking out loud” quality — with more space...
The low-code “market” isn’t really a market. Rather, I see it as an attribute of a software product, an implementation factor in how a product works. A product providing low-code capability says nothing about its intended value — it could be a product for sending emails, building automation rules, connecting APIs, or designing mobile forms.
What are termed “LCAP” (low-code application platform) software are often better described as “tools to build your own apps, without having to write all the code yourself.”
This post isn’t really about low-code as a marketplace descriptor, but about refining the nomenclature for...
After about 6-8 months of forging, shaping, research, design, and engineering, we’ve launched the Fulcrum Report Builder. One of the key use cases with Fulcrum has always been using the platform to design your own data collection processes with our App Builder, perform inspections with our mobile app, then generate results through our Editor, raw data integrations, and, commonly, generating PDF reports from inspections.
For years we’ve offered a basic report template along with an ability to customize the reports through our Professional Services team. What was missing...
A neat concept demo from Dhrumil Shah showing possible enhancements for Roam Research. He calls them “Roam-I” and “Roam-E”:
Roam-I — for reusing old knowledge
Roam-E — collaboration
Most of this is user interface on top of the core technology that underpins how Roam works, but it’s great to see people so passionate about this that they’ll spend this much time prototyping ideas on products they use.
I liked this newsletter post from Aron Korenblit on the no-code movement. The name overstates the problem as being with “code” in workflows, when the problem is really deeper than that:
How we feel about code —and why we want to avoid it— has in fact nothing to do it with code itself. Code is a language that helps us tell inanimate objects what to do so we don’t have to do it. Our real frustration lies with what usually comes with software projects: overblown budgets, long delays and expensive maintenance costs. That’s what we’re saying “no” to, not...
It’s common practice now in software development to do “continuous integration” — a constant reintegration of newly-written code with the master application to continuously run regression and unit tests, making the process of integrating new features a series of small efforts rather than one massive one at the end of a sprint cycle:
Many product teams have taken this principle to the next step and have learned that integration problems are time consuming, and that by integrating early and often (rather than a “phase” before testing), they can significantly speed up their overall throughput by minimizing the time that they...
This is another one from the archives, written for the Fulcrum blog back in 2016.
Engineering is the art of building things within constraints. If you have no constraints, you aren’t really doing engineering. Whether it’s cost, time, attention, tools, or materials, you’ve always got constraints to work within when building things. Here’s an excerpt describing the challenge facing the engineer:
The crucial and unique task of the engineer is to identify, understand, and interpret the constraints on a design in order to produce a successful result. It is usually not enough...
As we’ve started to adopt a process similar to Basecamp’s, we’ve been revisiting how we think about “backlogs” — the list of ideas and various requests we could work on in the product roadmap.
I liked this piece from Rich Ziade on the downsides of backlogs.
The term “backlog” makes me anxious. It implies being behind. It also implies that what you’ve got today is an incomplete thing. You need to get through that backlog. It also implies–dangerously–that this is the true unrealized ideal for a product.
After working on a (now) successful product for almost 10 years,...
An interesting article from Kevin Kwok on Superhuman’s (the email client) user acquisition cycle. An ultimate example of the product-led growth model. Good observations here on what they’re doing differently in having a product-centric strategy to drive the social referral loop. I liked this piece, about their hands-on, tailored onboarding process, which is almost totally unheard of in the consumer apps space:
Human Connection. Every onboarding at Superhuman is done by someone on their team. As importantly, because new users are already high intent, it feels far less transactional and sales oriented. And more aligned and focused...
Bryan wrote this up about the latest major release of Fulcrum, which added Views to the Editor tool. This is a cool feature that allows users doing QA and data analysis to save sets of columns and filters, akin to how views work in databases like PostgreSQL. We have some plans next to let users share or publish Views, and also to expose them via our Query API, with the underlying data functioning just like a database view does.
This’ll be a foundational feature for a lot of upcoming neat stuff.
What definition do we mean when we talk about product? Like being a “product company” or working in “product management”?
A few things spring to my mind — creating something for use by a customer that can be packaged and sold to many customers in a generalized form, done repeatably and sustainably in a process.
Marty Cagan has a cogent definition here that I really liked:
When I was being coached on the tech lead role, my engineering manager needed me to understand that when creating products for the real world, engineering was not enough. He drew on the whiteboard...
Honest postmortems are insightful to get the inside backstory on what happened behind the scenes with a company. In this one, Jason Crawford goes into what went wrong with Fieldbook before they shut it down and were acquired by Flexport a couple years ago:
Now, with a year to digest, I think this is true and was a core mistake. I vastly underestimated the resources it was going to take—in time, effort and money—to build a launchable product...
This is a cool little background post from Ryan Singer explaining the origins and his process behind Shape Up, a web book about product development.
One of the things he did when getting started (with no solid idea of how to approach it) was commit to giving a workshop on how Basecamp worked. This created a deadlined forcing function to compel him to come up with the initial content and framework:
I didn’t know how to write a book. But I did know how to give a workshop. So I put a call out on Twitter....
Evolution has a mysterious and amazing way of driving relentlessly toward simplicity and specialization:
Evolution figured outs its version of simplification. It (if you can imagine it talking) says, “Get all that useless crap out of the way. Just give me the few things I need and make them really effective.”
The question, then, is why complexity sells in the modern world.
Morgan Housel compares this phenomenon to why in the world of business, market motivations are almost always the reverse: consumers generally want a more complex product, service, or deliverable (or at least producers of goods convince...
An RTIN mesh consists of only right-angle triangles, which makes it less precise than Delaunay-based TIN meshes, requiring more triangles to approximate the same surface. But RTIN has two significant advantages:
The algorithm generates a hierarchy of all approximations of varying precisions — after running it once, you can quickly retrieve a mesh...
This is one from the archives, originally written for the Fulcrum blog back in early 2017. I thought I’d resurface it here since I’ve been thinking more about continual evolution of our product process. I liked it back when I wrote it; still very relevant and true. It’s good to look back in time to get a sense for my thought process from a couple years ago.
In the software business, a lot of attention gets paid to “shipping” as a badge of honor if you want to be considered an innovator. Like any guiding...
Earlier this year at SaaStr Annual, we spent 3 days with 20,000 people in the SaaS market, hearing about best practices from the best in the business, from all over the world.
If I had to take away a single overarching theme this year (not by any means “new” this time around, but louder and present in more of the sessions), it’s the value of customer success and retention of core, high-value customers. It’s always been one of SaaStr founder Jason Lemkin’s core focus areas in his literature about how to “get to $10M,...
Ryan Singer and the Basecamp team just released their new ebook on product development, called Shape Up, made available for free online. Me and some of our team here have already dug into it and are finding some interesting ideas to experiment with in our own product development cycles.
On shaping and wireframing:
When design leaders go straight to wireframes or high-fidelity mockups, they define too much detail too early. This leaves designers no room for creativity.
Appetites:
Whether we’re champing at the bit or reluctant to dive in,...
Basecamp’s Ryan Singer articulates well the struggles with adopting and truly getting value out of an agile workflow. The core problem most teams face isn’t that they’re bad at estimating time to completion, it’s that they don’t even know what exactly they’re trying to complete. Knowing the broad outline of the objective — like “refactor user management interface” or “build dashboarding system” — is one thing, and the team could all largely agree on the target. But it’s another thing entirely to break down each step along the way into a discrete element with...
Wireframing is a critical technique in product development. Most everyone in software does a good bit of it for communicating requirements to development teams and making iterative changes. For me, the process of wireframing is about figuring out what needs to be built as much as how. When we’re discussing new features or enhancements, rather than write specs or BDD stories or something like that, I go straight to a pen and paper or the iPad to sketch out options. You get a sense for how a UI needs to come together, and also for us visual thinkers, the new...
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...
Since I’m big on self-improvement and always looking for ways to get better at my professional craft, I was intrigued by this post from Marty Cagan from several years back. A post with a title the same as mine got me interested. Over the last few years I’ve occasionally read other companies’ job descriptions for that role to understand what they look for in skillsets and orientation.
It certainly matches broadly with my perception of the proper focus areas. I do think we’re particularly strong in what he terms “product culture”:
This was a long time in the making. We’ve launched our latest big feature in Fulcrum: photo annotations.
This feature was an interesting thing to take on. Rather than doing it the quick and dirty way, we did it right and built customized framework we could use across platforms. Because the primary interfaces for annotating are iOS and Android, the library is built in JavaScript and cross-compiled to each native mobile environment, which allows us to lean on a single centralized codebase to support both of our mobile platforms. We even have plans to build annotation support into our...
I’ve had R on my list for a long time to dig deeper with. A while back I set myself up with RStudio and went through some DataCamp stuff. This online book seems like excellent material in how to apply R to geostatistics.
Given where we are with Fulcrum in the product lifecycle, this rang very familiar on the struggles with how to listen to customers effectively, who to listen to, and how to absorb...
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...
We’re about to head to SaaStr Annual again this year, an annual gathering of companies all focused on the same challenges of how to build and grow SaaS businesses. I’ve had some thoughts on SaaS business models that I wanted write down as they’ve matured over the years of building a SaaS product.
I wrote a post a while back on subscription models, but in the context of consumer applications. My favorite thing about the subscription structure is how well it aligns incentives for both buyers and sellers. While this alignment...
