Boring apps? Add some SPARK!
A playbook for creating "must have" applications
I caught up with a friend of mine the other week who had a new startup. He was excited and energized—startups, particularly in the early days, can be an incredible euphoric rush! All the opportunity, doing exactly what you want to do, dreams galore.
Yet five minutes into the demo, it was clear as day that his product was going to fail—even though it was tackling an incredibly important topic (in this case, AI data quality). There were a ton of UI issues, but at the core, even though the technology might have been clever, it didn’t actually solve any problem that anybody had—it weirdly created more work for its users than doing nothing at all.
As a builder of software products, I’ve long been fascinated with understanding why some products succeed wildly, while others fail or struggle.
You don’t need to look far to see examples of both success and failure—Cursor.com, for example, is a hugely popular programming tool, yet it literally is built from a copy of the equivalent open source product from Microsoft (Visual Studio Code).
Cursor took on Microsoft, the world's largest software company, head-on and is unambiguously out-innovating them with a superior product. They are now at a billion-dollar revenue run rate! How did they pull this off?
Conversely, for every successful example, there are literally hundreds of startups that struggle or outright fail. Fauna.com, for example, arguably had some of the most advanced database technology on the planet. They solved many of the problems that bedevil software engineers with databases, including scaling, middleware complexity, and multi-tenancy support. Yet earlier this year, the company shut down. What happened?
While there are many factors behind the success or failure of a business, from go-to-market to funding to culture, for this post, I want to focus on product.
What makes great products great?
There are countless product development frameworks out there—two of my favorites are “Jobs to be Done” by Clayton Christensen and Don Norman’s Emotional Design
Jobs to be Done can be summarized with a pithy line: customers don’t buy products; they hire them to get a specific job done in their lives. Or as Theodore Levitt said: “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
Similarly, Emotional Design is all about crafting delightful experiences. Both the Porsche 911 and the East German Trabant solve the “job to be done” of transportation. Yet one of them arguably is more delightful than the other!
Over the years, I’ve tried many different frameworks, none of which have been comprehensive enough. There are beautiful products that don’t actually solve any real problems—think of the animated cybersecurity threat maps that are fun to look at but don’t actually solve much in the way of cybersecurity. Or my friend’s new startup that solved a key AI accuracy problem, but in an impenetrably complex way.
Recently, I’ve found myself articulating the same principles across all the companies I’ve worked with. It boils down to creating some SPARK!
TL;DR
SPARK is a five-point product lens to build software people adopt, love, and trust:
Simple — dead-obvious conceptual model; learning curve ≈ flat.
Purposeful and Prioritized— solves a problem that matters now; no fluff, no bloat.
Attractive and Attentive— emotionally appealing; sparks delight and pride in use.
Reliable — it doesn’t flake; trust via uptime, consistency, and polish.
Known — aims at problems users already know they have.
Treat it as a checkpoint you can run in 30–60 minutes at any stage—from napkin sketch to GA. To be clear, it’s not a guarantee of success—there are still many other factors at play, such as pricing, marketing, and other go-to-market activities! But I can easily argue that if your product struggles in any of the SPARK dimensions, it’s likely to struggle in the marketplace.
What SPARK Is (and isn’t)
This is not a new process religion. Keep Scrum, Shape Up, or Continuous Discovery—whatever gets you shipping. SPARK is a lens you pass your product through to expose weak spots you’ll otherwise rationalize away.
S · Simple
The conceptual model is obvious. The conceptual model is: “What do you need to know to use the product?” In the iPhone, for example, everything is an app, and as long as you know how to touch and tap, you can use an iPhone. Users shouldn’t need onboarding videos to accomplish their first meaningful task.
Ask: Can a new user tell what the primary object is and what they can do to it? (Channel → post. Doc → edit. Ticket → purchase.)
Try this: Explain your product in one sentence using one noun and two verbs. If you can’t, your model is likely muddy.
P · Purposeful and Prioritized
You’re solving a burning job—not just building features.
Ask: What bad thing happens if this job remains unsolved a month from now? Not three years from now, but right now.
Try this: Strip your roadmap to three outcomes customers would pay to accelerate. If a feature doesn’t move one of these outcomes, cut it.
A · Attractive
Delight is a feature. Emotional resonance drives adoption, retention, and word-of-mouth.
Ask: Where are the “mini-wow” moments? Auto-correct as you type. One-click sharing. An animated chart that makes your user look brilliant in a meeting. Even something as simple as the “hoot” sound the Owl meeting camera makes when booting up.
Try this: Mark three moments in your flow where a subtle animation, sound, or copy spark will earn a grin.
R · Reliable
Trust shows up as absence: no crashes, no weird states, no pauses, no “try again.” In B2B products, especially, flaky = dead. Note that reliability is not just about crashes and failures; speed also counts! As I write this, I am using the Grammarly.com checker. I doubt I’d be as satisfied if a grammar check took two hours, even if it was more accurate!
Ask: What’s the ugliest failure mode today? How do we prevent it, not just handle it?
Try this: Adopt a “reliability measure” alongside your definition of done (SLOs, gold-paths, edge-paths).
K · Known
Build for problems users already know they have. This is sometimes the hardest for innovators and entrepreneurs. Almost by definition, if you are building a startup or a new product, you are solving a problem that the world has not yet solved! Yet if the world doesn’t care yet about solving the problem, it doesn’t matter.
I often struggle with this balance! My very first startup built an early form of what we would now call cloud computing. It was “obvious” that the future was running software across many machines all over the world. In 2025, nobody really debates that—it’s how AWS, Azure, Google, and pretty much everything on the Internet runs. But I was trying to do this in 1991! Even if I was “right” in concept, I was very wrong in my timing.
Ask: What would your buyer ask ChatGPT the week before purchase?
Try this: Show your solution to as many prospective customers as possible. If they say “I would buy that right now”, you likely have a winner. If they pay you right away even before you’ve finished the product, even more likely that you have a winner!
Has This Been Done Before?
Yes—and no. SPARK stands on the shoulders of giants and stitches their best ideas into a fast, memorable check.
Don Norman’s Emotional Design → A (Attractive): visceral/behavioral/reflective layers explain why beauty and micro-joy matter. SPARK bakes this into a non-negotiable.
Jobs to Be Done → P (Purposeful) + K (Known): JTBD uncovers the job; SPARK biases toward known and understood pain over latent needs to speed adoption.
Lean Startup & Opportunity Trees → P: iterate toward outcomes, map opportunity space. SPARK complements them by insisting on S, A, and R too.
EG-SAT / Emotional Goal frameworks → A: academic precision, tough to operationalize; SPARK keeps the heart, drops the overhead.
Nielsen Heuristics / Double Diamond → S: processes that tend to yield simplicity; SPARK elevates simplicity as a gate, not a byproduct.
Reliability & Trust: too many UX frameworks underweight this. SPARK puts R on the masthead because uptime, speed and predictability sell.
Using SPARK in the Wild: a 60 minute exercise
0–10 min · Frame
What’s the one-sentence noun+verbs? Who’s the buyer? What do they already call their problem?
10–25 min · Walk the primary flow
Start-to-value. At each step, mark S/P/A/R/K with ✅ or ❌. Capture concrete fixes.
25–40 min · Kill a pet feature
If it doesn’t move P or K, it’s on probation. If it also hurts S or R, it’s gone.
40–55 min · Design one mini-wow
Pick a dull step and inject a tiny delight that also speeds the task.
55–60 min · Commit
Write the three simplest changes that raise your SPARK score this sprint.
Pro tip: rerun a quick SPARK test after customer calls and again before each release. It keeps excellence from being “someone’s job” and turns it into team muscle memory.
A quick SPARK self-test
Score each 1–5 (be brutally honest):
S: First-time user can do the core job in < 2 minutes without docs.
P: If we turned it off tomorrow, 40% of users would be very disappointed.
A: We can point to 3 concrete “mini-wow” moments.
R: We meet published SLOs, and our top 3 bugs are prevention-fixed.
K: Our homepage names the buyer’s exact, searchable problem.
25 = you’re cooking. 18–24 = focused iteration. <18 = stop shipping net-new; fix foundations.
FAQs
What about breakthrough products with no “known” need?
Even the new-new benefits ride on a known pain at first. The iPhone didn’t sell “apps”; it sold “a real web browser in your pocket.” Anchor on today’s pain, reveal the new superpower once they’re in.
Is “Attractive” just lipstick?
No. Attractive experiences reduce cognitive load, signal quality, and create pride. People advocate for products that make them look and feel smart.
Does Reliability slow us down?
Only if you bolt it on at the end. When you choose a clearer model (S), constrain scope (P), and remove fancy-but-flaky flourishes (A), reliability gets easier, not harder.
Why should I care?
AI makes it cheap to ship something. That’s not the bar. The winners won’t be the teams who ship the most, but the ones who ship Simple, Purposeful, Attractive, Reliable, Known—on repeat. Good enough software will go by the wayside. Ship something great!
Last but not least, SPARK is not the definitive, be-all, end-all. I’ve love feedback and discussion on how to do even better!