Archive of posts with tag 'Product Development'

MVPs with Cursor →

March 11, 2025 • #

Good stuff here on building with Cursor. Some takeaways:

Use starter kits to bootstrap project directories
Build assistive docs to help the Agent. Remember that the Agent behaves a lot like a human:
- A human with minimal guidance doesn’t infer the right choices
- PRDs, app flows, tech stacks / API docs, frontend/backend guidelines all help it do what you want
project rules over .cursorrules
- More flexible
- Sync across teams
- Fine-tune based on tech stack

I’ve had much better results getting in the weeds with PRDs well before having agents go off and build. And you can have multiple AIs work on and refine your documents, too.

✦

We Did All This Discovery, Now How Do We Decide? →

February 25, 2025 • #

When capturing hundreds of problems during product discovery, we generate at least as many potential solutions. We can’t build everything at once, so how do we decide what to tackle first? Ryan Singer has a suggestion:

The counterintuitive thing is, we often feel like our task is to get to a “yes.” But what we actually need is a way to say “no.” It’s the ability to eliminate many, many things that aligns us on the one thing. It’s the “no, no, no, … YES!” that gives us the power to move forward and to stick with a project.

Finding the “reasons to build” for any given solution is easy — every idea is “good” on some continuum. When faced with a hundred ideas, each with compelling reasons to build it, we’re left with the fuzzy question of “how good?”

Ryan’s suggestion inverts the question: look for the reasons to not build it. Is there a workaround? Is it merely annoying but not a dealbreaker? What are users doing today instead? What are the real consequences of the status quo?

This inversion approach is more likely to highlight the acute pains — the missing solutions causing real negative consequences, the ones with no good alternatives or workarounds.

The first key to prioritizing is to triage the obvious “not now”s first. If we can cut our list down significantly, we can focus attention on where we’ll make the biggest impact.

✦

Product-led Growth Isn't Incompatible with Sales

September 1, 2021 • #

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, imagining that these are mutually exclusive models — to grow, you can do it through self-service or you can hire a huge sales team, pick one. Even if it’s not described in such stark terms, claims like “they did it without sales” position sales as a sort of necessary evil we once had to contend with against our wills as technology builders.

But all of the great product-led success stories (including those mentioned above) include sales as a component of the go-to-market approach. Whether they refer to the function being performed by that name or they prefer any number of other modern euphemisms (customer happiness advocate, growth advisor, account manager), at scale customers end up demanding an engagement style most of us would call “sales.”

Product-led, self-service models and sales are not incompatible with one another. In fact, if structured well, they snap together into a synergistic flywheel where each feeds off of the other.

Early-stage customers

Product-led tactics have the most benefit in the early stage of a customer’s lifecycle, when your product is unproven. Free trials and freemium options lower the bar to getting started down to the floor, self-service tools allow early users to learn and deploy a tool in hours on their own timeline, and self-directed purchasing lets the buyer buy rather than be sold to. In 2021, flexibility is table stakes for entry-level software adoption. There are so many options now, the buying process is in the customer’s control.

With the right product design, pricing, and packaging structure, customers can grow on their own with little or no interaction through the early days of their expansion. For small to mid-size users, they may expand to maximum size with no direct engagement. Wins all around.

For larger customers (the ones all of us are really after in SaaS), this process gets them pretty far along, but at some stage other frictions enter the picture that have nothing to do with your product’s value or the customer’s knowledge of it. Financial, political, and organizational dynamics start to rear their heads, and these sorts of human factors are highly unlikely to get resolved on their own.

The Sales Transition

Once the bureaucratic dynamics are too great, for expansion to continue we need to intervene to help customers navigate their growing usage. As I wrote about in Enterprises Don’t Self-Serve, several categories of friction appear that create growth headwinds:

Too many cats need to be herded to get a deal done — corralling the bureaucracy is a whole separate project unrelated to the effectiveness or utility of the product; no individual decision maker

The buyer isn’t the user — user can’t purchase product, purchaser has never used product; competing incentives

If you have an advocate, they have a day job — And that job isn’t playing politics with accounting, legal, execs, IT, and others

As you start encountering these, you need to proactively intervene through sales. The role of sales is to connect with and navigate the players in the organization, then negotiate the give and take arrangements that create better deals for both parties: e.g. customer commits to X years, customer gets Y discount. Without a sales-driven approach here, every customer is treated as one-size-fits-all. Not the best deal for the vendor or customer. When you insert sales at the right stage, you increase the prospect of revenue growth, and the customer’s ability to sensibly scale into that growth with proper integration throughout their organization.

In SaaS literature you’ll read about the notion of “champions”, internal advocates for your product within your customer that are instrumental in growing usage. Champions serve a function in both methodologies — with product-led, they’re pivotal for adoption to perpetuate itself without your involvement, and when engaging with sales, we need those champions to be intermediaries between vendor and buyer. They act like fixers or translators, helping to mediate the communication between the sides.

A well-built, product-led product mints these champions through empowerment. We give users all the tools they need — documentation, guides, forums, SDKs — to build and roll out their own solution. After a couple phases of expansion, users evolve from beginners to experts to champions. If we’re doing it right and time sales correctly, champions are a key ingredient to maximizing relationships for customers and product-makers. Product-led approach early creates inertia to keep growing, a back pressure that sales can harness to our advantage.

AppCues publishes their product-led growth flywheel, which describes this cycle succinctly:

As they demonstrate, a user becoming a champion isn’t the end state; champions beget future brand new users through advocacy, word-of-mouth, and promotion within their own networks.

It’s dangerously short-sighted to look down the nose at sales as a bad word. Sales isn’t just something you resort to when you “can’t do PLG”, it’s a positive-sum addition to your go-to-market when you execute this flywheel properly.

✦

A Nomenclature for Low-Code Users

July 7, 2020 • #

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 how we talk about users we have in mind when designing low-code tools. Who are we building them for? Who needs them the most?

As Aron Korenblit wrote a few months back, low-code as a term isn’t really about code, per se, but often things like process modeling, workflows, data flows, data cleanliness, speed of prototyping, and low cost trial and error:

If what we’re trying communicate is that no-code helps get things done faster, we should elevate that fact in how we name ourselves instead of objecting to code itself.

For many years, all sorts of tools from Mailchimp or Webflow to Fulcrum or Airtable provide layers of capabilities for a continuum of user types, moving from the non-technical through to full developers. The non-tech space wants templates and WYSIWIG tools, the devs want an API, JavaScript customization, and full HTML/CSS editing suites. I think a two-type dichotomy isn’t descriptive enough, though. We need a third “semi-technical” user in the middle.

The spectrum of users could look something like this — we analogize these to an Microsoft Excel user equivalent (parenthesized):

Novice — anything that looks like code is totally opaque to novices. They’re scared off by it and afraid to change anything for fear of breaking something (Can enter data in Excel, and maybe do some sorting, filtering, or data manipulation)
Tinkerer — can parse through code examples and pre-existing scripts to roughly understand, uses trial and error and small adjustments to modify or piece together snippets for their own use case; often also can work with data and data tools like database applications and SQL (Can use formulas, pivot tables, lookups, and more with Excel, comfortable slicing and dicing data)
Developer — fluent in programming languages; excited about the prospect of writing their own code from scratch, just wants to be pointed to the API docs (Can write VBScripts and macros in Excel, but mostly wants to escape its confines to build their own software)

Of course empowering the Novices is one of the primary goals with low-code approaches, as they’re the least prepared to put together their own solutions. They need turn-key software.

And we can help Developers with low-code, too. If we can bootstrap common patterns and functionality through pre-existing building blocks, they can avoid repetitive work. Much of tool-building involves rebuilding 50-75% of the same parts you built for the last job, so low-code approaches can speed these folks up.

But the largest gap is that middle bunch of Tinkerers. Not only do they stand to gain the most from low-code tools. From my observations, that group is also the fastest-growing category. Every day as more tech-native people enter the workforce, or are compelled to dive into technical tools, people are graduating from Novice to Tinkerer status, realizing that many modern tools are resilient to experimentation and forgiving of user error. The tight feedback loops you can get from low-code affordances provide a cushion to try things, to tweak, modify, and customize gradually until you zero in on something useful. In many cases what a user decides is a “complete” solution is variable — there’s latitude to work with and not an extremely rigid set of hard requirements to be met. By providing building blocks, examples, and snippets, Tinkerers can home in on a solution that works for them.

Those same low-code tactics in user experience also give Novices and Tinkerers the prototyping scaffolds to build partial that can be further refined by a Developer. Sometimes the prototyping stage is plenty to get the job done, but even for more complex endeavors can greatly reduce cost.

✦

Weekend Reading: Product Market Fit, Stripe's 5th Hub, and Downlink

May 11, 2019 • #

🦸🏽‍♂️ How Superhuman Built an Engine to Find Product/Market Fit

As pointed out in this piece from Rahul Vohra, founder of Superhuman, most indicators around product-market fit are lagging indicators. With his company he was looking for leading indicators so they could more accurately predict adoption and retention after launch. His approach is simple: polling your early users with a single question — “How would you feel if you could no longer use Superhuman?”

Too many example methods in the literature on product development orient around asking for user feedback in a positive direction — things like “how much do you like the product?”, “would you recommend to a friend?” Coming at it from the counterpoint of “what if you couldn’t use it” reverses this. It makes the user think about their own experience with the product, versus a disembodied imaginary user that might use it. It brought to mind a piece of the Paul Graham essay “Startup Ideas”, if you go with the wrong measures of product-market fit:

The danger of an idea like this is that when you run it by your friends with pets, they don’t say “I would never use this.” They say “Yeah, maybe I could see using something like that.” Even when the startup launches, it will sound plausible to a lot of people. They don’t want to use it themselves, at least not right now, but they could imagine other people wanting it. Sum that reaction across the entire population, and you have zero users.

🛤 Stripe’s Fifth Engineering Hub is Remote

Remote work is creeping up in adoption as companies become more culturally okay with the model, and as enabling technology makes it more effective. In the tech scene it’s common for companies to hire remote, to a point (as Benedict Evans joked: “we’re hiring to build a communications platform that makes distance irrelevant. Must be willing to relocate to San Francisco.”) It’s important for the movement for large and influential companies like Stripe to take this on as a core component of their operation. Companies like Zapier and Buffer are famously “100% remote” — a new concept that, if executed well, gives companies an advantage against to compete in markets they might never be able to otherwise.

🛰 Downlink

A neat Mac app that puts real-time satellite imagery on your desktop background. Every 20 minutes you can have the latest picture of the Earth.

✦

New Things In New Ways, or Same Old Things In Old Ways? →

May 2, 2019 • #

This latest piece from Steven Sinofsky considers product strategy on 2 axes:

What problem is being solved and
How it is solved

The spectrum he paints here runs from the most conservative (old things in old ways, “incrementing”) to the most forward-leaning (new things in new ways, “inventing”). No approach in this matrix is “the answer” in all cases, each has its merits based on timing, product type, stage, customer set, sales approach, or business model. Also a product team growing over a course of 5 to 10 years shouldn’t necessarily always be in a single quadrant on the matrix. It’s helpful to use as a lens to view your own team through.

Why is this so tricky? Because almost nothing we use is entirely new,an invention. Facebook was not the first social network. Instagram wasn’t the first way to share photos. Google wasn’t the first search engine with ads or ad network. Windows wasn’t the first graphical OS. Word, Excel and more were hardly the first productivity tools in those categories.

Yet those products were all very innovative. Innovative products are a portfolio of new and old that lead to creative solutions. Marco Iansiti at Harvard Business School once taught me, innovation = invention + impact. The impact can be to solve new problems, changing market perspectives on categories, or causing customers to consider new ways to use technology.

What this brings front of mind when I think about my own past efforts, or even other products I follow in the market, is that teams focus to much on the new things rather than the new ways. Different approaches to tech platform architecture, deployment strategy, or even productization (pricing and packaging) can often be keys to unlocking new customers or growth with existing ones.

✦

Weekend Reading: Shanghai, Basecamp, and DocuSaurus

January 26, 2019 • #

🇨🇳 195-Gigapixel Photo of Shanghai

Shot from the Oriental Pearl Tower, the picture shows enormous levels of detail composited from 8,700 source photos. Imagine this capability available commercially from microsatellite platforms. Seems like an inevitability.

🏕 How Basecamp Runs its Business

I, like many, have admired Basecamp for a long time in how they run things, particularly Ryan Singer’s work on product design. This talk largely talks about how they build product and work as an organized team.

📄 Docusaurus

This is an open source framework for building documentation sites, built with React. We’re currently looking at this for revamping some of our docs and it looks great. We’ll be able to build the docs locally and deploy with GitHub Pages like always, but it’ll replace the cumbersome stuff we’ve currently got in Jekyll (which is also great, but requires a lot of legwork for documentation sites).

✦

A Product Origin Story

September 11, 2018 • #

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 same issue: getting accurate field reporting from a deskless, mobile workforce back to a centralized hub for reporting and analysis. While we knew it wasn’t a brand new invention to create a data collection platform, we knew we could bring a novel solution combining our strengths, and that other existing tools on the market had fundamental holes we saw as essential to our own business. We had a few core ideas, all of which combined would give us a unique and powerful foundation we didn’t see elsewhere:

Use a mobile-first design approach — Too many products at the time still considered their mobile offerings afterthoughts (if they existed at all).
Make disconnected, offline use seamless to a mobile user — They shouldn’t have to fiddle. Way too many products in 2011 (and many still today) took the simpler engineering approach of building for always-connected environments. (requires #1)
Put location data at the core — Everything geolocated. (requires #1)
Enable business analysis with spatial relationships — Even though we’re geographers, most people don’t see the world through a geo lens, but should. (requires #3)
Make it cloud-centric — In 2011 desktop software was well on the way out, so we wanted an platform we could cloud host with APIs for everything. Creating from building block primitives let us horizontally scale on the infrastructure.

Regardless of the addressable market for this potential solution, we planned to invest and build it anyway. At the beginning, it was critical enough to our own business workflow to spend the money to improve our data products, delivery timelines, and team efficiency. But when looking outward to others, we had a simple hypothesis: if we feel these gaps are worth closing for ourselves, the fusion of these ideas will create a new way of connecting the field to the office seamlessly, while enhancing the strengths of each working context. Markets like utilities, construction, environmental services, oil and gas, and mining all suffer from a similar body of logistical and information management challenges we did.

Fulcrum wasn’t our first foray into software development, or even our first attempt to create our own toolset for mobile mapping. Previously we’d built a couple of applications: one never went to market, was completely internal-only, and one we did bring to market for a targeted industry (building and home inspections). Both petered out, but we took away revelations about how to do it better and apply what we’d done to a wider market. In early 2011 we went back to the whiteboard and conceptualized how to take what we’d learned the previous years and build something new, with the foundational approach above as our guidebook.

We started building in early spring, and launched in September 2011. It was free accounts only, didn’t have multi-user support, there was only a simple iOS client and no web UI for data management — suffice it to say it was early. But in my view this was essential to getting where we are today. We took our infant product to FOSS4G 2011 to show what we were working on to the early adopter crowd. Even with such an immature system we got great feedback. This was the beginning of learning a core competency you need to make good products, what I’d call “idea fusion”: the ability to aggregate feedback from users (external) and combine with your own ideas (internal) to create something unified and coherent. A product can’t become great without doing these things in concert.

I think it’s natural for creators to favor one path over the other — either falling into the trap of only building specifically what customers ask for, or creating based solely on their own vision in a vacuum with little guidance from customers on what pains actually look like. The key I’ve learned is to find a pleasant balance between the two. Unless you have razor sharp predictive capabilities and total knowledge of customer problems, you end up chasing ghosts without course correction based on iterative user feedback. Mapping your vision to reality is challenging to do, and it assumes your vision is perfectly clear.

On the other hand, waiting at the beck and call of your user to dictate exactly what to build works well in the early days when you’re looking for traction, but without an opinion about how the world should be, you likely won’t do anything revolutionary. Most customers view a problem with a narrow array of options to fix it, not because they’re uninventive, but because designing tools isn’t their mission or expertise. They’re on a path to solve a very specific problem, and the imagination space of how to make their life better is viewed through the lens of how they currently do it. Like the quote (maybe apocryphally) attributed to Henry Ford: “If I’d asked customers what they wanted, they would’ve asked for a faster horse.” In order to invent the car, you have to envision a new product completely unlike the one your customer is even asking for, sometimes even requiring other industry to build up around you at the same time. When automobiles first hit the road, an entire network of supporting infrastructure existed around draft animals, not machines.

We’ve tried to hold true to this philosophy of balance over the years as Fulcrum has matured. As our team grows, the challenge of reconciling requests from paying customers and our own vision for the future of work gets much harder. What constitutes a “big idea” gets even bigger, and the compulsion to treat near term customer pains becomes ever more attractive (because, if you’re doing things right, you have more of them, holding larger checks).

When I look back to the early ‘10s at the genesis of Fulcrum, it’s amazing to think about how far we’ve carried it, and how evolved the product is today. But while Fulcrum has advanced leaps and bounds, it also aligns remarkably closely with our original concept and hypotheses. Our mantra about the problem we’re solving has matured over 7 years, but hasn’t fundamentally changed in its roots.

✦

Recent Links: Mapping Air Quality, the Problem with Agile, Indie Jazz

November 29, 2017 • #

⏱ Mapping Street-Level Air Quality in California

This is amazing work by Google putting air quality sensors on their Street View cars to collect air quality data. The resolution of this is amazing — to see how drastically the pollutant level changes from street to street.

🏔 Running in Circles

I love Ryan Singer’s perspective on product development. In this post he levels critique at the now-commonplace “agile” software development process. It’s been distorted into a simplistic set of tactical process methods (building in “cycles”), and has lost what its original value was as an upgrade from the old school “waterfall” approach.

Agile became synonymous with speed. Everybody wants more, faster. And one thing most teams aren’t doing fast enough is shipping. So cycles became “sprints” and the metric of success, “velocity.”

But speed isn’t the problem. And cycles alone don’t help you ship. The problems are doing the wrong things, building to specs, and getting distracted.

🎷 The Best Jazz on Bandcamp: October 2017

Bandcamp’s blog is one of my favorite places to find new music these days. They do an excellent job surfacing the interesting things from the community and featuring them like this. Must be some real music nerds over there; just browse their blog post titles and see what I mean.

✦

We Need Product Storytellers →

April 7, 2012 • #

A great article from UXMAG making the case for “product storytellers” on product teams, instead of more marketing or product management. A must-read for creators trying to bring products to market. This statement gets to the heart of the problem with struggling products — the what and how of the product get put above the why:

The root cause of these symptoms is the fact that execution focuses on the how and what of a product. But in a world where consumers are inundated with choices, products that want to be noticed and adopted must be rooted in the why.

A product is more than an idea, it’s more than a website, and it’s more than a transaction or list of functionalities. A product should provide an experience or service that adds value to someone’s life through fulfilling a need or satisfying a desire. The ultimate question then becomes: who identifies that value? After the executive or stakeholder identifies the initial idea, who in the organization ensures that the product and experience deliver value to the user? Maybe it isn’t the product manager, marketer, technologist, or designer; perhaps what we need is a new role: the product storyteller.

✦

Browse the full archive →

✦