Managing Product Development by Integrating Around Concerns

by Ryan Singer (@rjs)

This article was originally posted to in April 2012.

I’ve been asked to explain my approach to managing product development. This topic applies to individual designers and programmers as much as managers. The goal is not to take what we already do and do it faster or more efficiently. The goal is to have more information and flexibility in our process so we can make better decisions and better products.

If you build the same product over and over, this article is probably not for you. I work on new things and I never know how long it will take or what will work and what won’t. Therefore I design my approach for dealing with unknowns.

When I start designing and developing a product, it doesn’t exist yet. There are a lot of intentions and expectations and aims, but nothing to ship to users. And while the product doesn’t exist yet, there are hundreds of individual points I can imagine should be addressed. Take for example a product for managing conferences. I know there should be an event setup process, a registration form, a check-in process, payment processing, ways to apply credits and discounts, and more. All of these things are contingencies waiting to be proved out by a real design and real implementation.

Each of these broad areas of concern is itself made up of many smaller contingencies. The registration form contains specific fields, validation rules, error states, browser compatibility, art direction, and more. Then down to the programming, all of the elements should be implemented with well-factored functions that reliably perform their roles and allow for easy change and maintenance.

If you take all these levels of contingencies across all the areas of concerns you have a lot to account for in a product that doesn’t exist. And that doesn’t even touch on interconnections and dependencies between concerns.

So how do we manage all this? I like to imagine this mass of contingencies as an unmapped terrain. The terrain is everything needed to solve the customer’s problem, and my responsibility is to map and explore the whole thing. In order to know what has been explored and settled and what is still wilderness, I want to have some areas defined on the map.

The illustrations are just to show how I visualize them. In practice, I track these areas in plain list form.

In list form

After I have a lay of the land, the next step is to determine what to work on first, second, third etc. Not every concern in the product provides equal value to the customer. Some parts are core to the problem. Without them the app has no purpose. Others are necessary but have nothing to do with the domain, like user-authentication. As I look at these different areas on the map, I ask myself three important questions:

  1. How valuable is this, from the perspective of the customer’s problem?
  2. How necessary is this, from nice-to-have to must-have?
  3. How far do I have to take it? How good should this particular piece be in order to call it ”done” and move on?

It’s crucially important to understand: all parts of the product do not have equal value. Designers and programmers have a tendency to make everything they work on as good as possible. Once you go beyond a baseline standard of quality, this tendency can lead you to over-deliver on features that don’t matter at the expense of more important features. (See my article on user experience in a minimum viable product.)

In order to get moving on the product, I will do a rough ranking to determine which areas are most important per the three questions above. This is what Getting Real calls finding the epicenter.

A good way to think about this is: which parts of the app will teach me the most about the problem by working on them? This is the exact opposite of what programmers often do when they build the “knowns” first, like user-authentication, before they dig into the hairier domain-specific features.

The end result of this ranking is something like a heat map that reflects my assumptions about where the value is in the product.

Where the value is

I don’t care about ranking every single area. The point is to identify the top few things I need to focus on first. After I hit the top items, I can repeat the ranking process and find the next most important thing, cycling like that until everything is done.

In this case, customers for the conference management product get the most value out of the online registration form and payment processing. They basically hire the product to allow attendees to sign up online and pay. A close second to that are reports on the registrations so far. Customers use those to figure out how big the venue should be and how many sandwiches to order for lunch. Beyond that, it’s necessary to provide things like user authentication and account management, but these are secondary to the domain-specific areas. Finally there are some nice-to-haves like data export which would be fine to ship without.

Now it’s time to do some work. Say we are starting with the registration form, the most important item. The interface design comes first because I want the design to drive the decision tree, not programmer convenience. As I pull out my pen and paper to sketch the UI, I realize there is still a lot to figure out.

The registration form is itself a cluster of contingencies. There is more to the flow than just a form. What happens on success? What happens on failure? Are there email templates involved? If I don’t note these things, I won’t be sure to hit them all. In order to get a clear view of all the pieces, I repeat the same mapping exercise from before but scoped to the registration form area. It’s a recursive process.

Map of the registration form concern

Now the concerns are low-level enough to design. I start designing the form, first sketching the different states and then implementing static mocks and templates. Soon I’m far enough to bring a programmer in. This is when the real ”management” begins.

The natural approach most people take at this point is to divide the work by role. They create a ”design” todo list and a ”programming” todo list.

Todos by role

The problem with this approach is nobody can glance at these two lists and absorb a ”state of the world” from them. They don’t correspond to a map.

Here is the same todo list refactored to show areas of concern instead of division of roles:

Todos by concern

When I look at lists like this I can see exactly how each aspect of the registration form is coming along. Whenever a list is finished, it shows a piece of the product is ready to review and mark ”done.” It feels great to know one part of the product has no remaining contingencies. It’s ready to go.

Marking one piece ”done” is powerful because it requires design, programming, support and review to integrate around a specific point in the product. When the programmer has questions about the design all the forces and constraints are fresh in the designer’s mind. Likewise when QA or support raise an issue, the programmers don’t have to pull out their archeological tools. The code is still fresh and programmers can anticipate exactly where to look to improve the issue. When all parties are present it gives reviewers the maximum possible leverage because all aspects of the team are available and prepared to act on feedback.

These benefits are the same whether you work alone, with another person, or a larger team. The prize is productive focus and the steady, gradual transformation of contingencies into settled facts. As you shift focus from one area to the next you can conquer and resolve territories on the map. It feels great to check off whole globs of contingencies and wipe them off your mental plate.

Progress over time

At any given time, I want to ask ”where are we?” and see something like this map reflected in the project’s todo lists. I want to know what is done, what’s not done, which aspects are ”solved” and which are still open. Grouping the hundreds of low-level contingencies into higher-order units of concern has enabled me to keep this clear view on all the substantial projects I’ve managed over the past few years.

This article touched on a number of important points:

  • View undeveloped parts of the product as contingencies, not truths.
  • Bundle contingencies into areas of concern so you have a mental map of the main pieces of the product.
  • Consciously judge the value of each area, with regard to how necessary it is and also how domain-specific it is. Don’t be fooled by focusing on “necessary” things that don’t differentiate, like user authentication.
  • Areas of concern are themselves bundles of contingencies, and you can recursively apply the same analysis to find where the value is and what needs to be done.
  • Tracking work by role doesn’t show progress. Group tasks by concern so checking off a set of contingencies means you have covered all aspects of one piece of the product and you can move on.
  • Integrating all roles around one piece of work allows everyone to keep the problem in context while feedback, pushback and new insights arise.
  • A healthy development process is a steady, gradual transformation of unproved contingencies into settled facts.
  • The goal is a clear head focused on outstanding unknowns. The manager should be able to ask “where are we?” at a high-level at a given moment and see what is done, what is not, what’s in process, what is open, what is satisfactory and what isn’t.

Since this post covers so much ground in summary form, I would be happy to elaborate on specific points. Please share your thoughts or questions in the comments or via Twitter at @rjs.

Next Story — Want to Understand Design Forces?
Currently Reading - Want to Understand Design Forces?

Want to Understand Design Forces?

Untangle design conversations into the forces bearing on the design, the solutions under consideration, and the fitness between the two.

I wrote some Tweets today about separating forces from solutions when you discuss design ideas.

A few people asked me to explain what forces are and to provide more detail on this. Here are some thoughts.

Think that you’re building a bridge.

There are facts about the world that you must accept in order to make a bridge that holds weight. These are the forces that act upon whatever bridge you build. You take the forces into account in your design so that your bridge stands.

Those physical forces are functional. They affect whether the thing works or not. There are also emotional and social forces. The bridge project may be perfectly engineered, but if the aesthetics aren’t appealing to a stakeholder, the project won’t be approved. Therefore you can consider the stakeholder’s demands on style as a force in the design task.

The leap to make in this metaphor is picturing what it means for your design to “stand” or to “hold weight.” We don’t have clear physical laws telling us whether our app will “bear the load” of our users’ behavior. The metaphor is useful because it encourages you to define things you believe to be true about the world outside the thing you’re building, and then treat those things as if they were physical laws.

It’s about better conversation.

If you’re building a bridge and your team doesn’t agree on the laws of physics, collaborating will be difficult. By agreeing on the forces that bear on the design, you can productively (and playfully) explore solutions and agree on how to evaluate them. This is just as true when you work on a problem alone.

When you’re not building a bridge, you need to come up with the “laws of physics” yourself. What will people do with the design, how will they stress it, where will they bend it? This falls under domain knowledge and life experience. You can express what you agree upon as forces on the design. For example, the to-do tracking feature will be different if the team agrees that users often need to reassign items. The kitchen design will be different if you assume the user cooks for four people or for fifty people.

Another analogy is the windmill. If you don’t know whether to face it toward the right or toward the left, you study where the wind blows. Similarly we answer questions about how to shape the design solution by inquiring into the forces that bear on it.

Whether you do user research, reflect on personal experience, or arbitrarily decide what the truth is, that’s up to you. The benefit to your design process comes from untangling the design conversation into three things: the forces bearing on the design, the solutions under consideration, and the fitness between these two.

(I gave a talk on this back in 2010:

(PS. If you’re wondering how this relates to job-to-be-done theory, the JTBD tools are ways to find and define the primary forces. When you figure out what a person is trying to do and how they judge progress, you can treat that information as if it was physical law and then design against it. )

Next Story — The Apple-Google shift
Currently Reading - The Apple-Google shift

The Apple-Google shift

In the last couple of years, two very distinct things have happened — or, to be more precise, been happening — in the world of consumer tech, in my opinion. A shift has occurred: Apple, once the definition of innovation, has become stale, content to rest on its laurels; while Google, once ugly and disparate, has continually pushed forward with new and better products that are a delight to use.

The result is two-fold: firstly, from a software perspective, Google-authored apps have all but replaced Apple’s defaults on my iPhone; secondly, for the first time ever, I find myself potentially choosing a Google phone over an Apple phone — a choice that represents not just a one-off hardware purchasing decision, but a first tentative step outside of Apple’s ecosystem and, as a result, a break in unashamed Apple fanboy-ism.

Okay, so I’m considering a switch to Android. No big deal. I’m following in the footsteps of many, many, many others. But what I find interesting outside of my own personal decision is that there seems to be a growing discontent with Apple — especially amongst former so-called fanboys/girls — and, at the same time, a growing appreciation of what Google have been doing, especially from a design perspective. In many ways it’s unwise to compare these two companies alone, but few would disagree that these days they’re the two sides of one coin.

So I thought I’d try and pick this apart. What’s actually changed?

It’s not that Apple no longer creates great products, but there’s just not that spark there anymore, is there? Remember when a new MacBook or iMac would launch? Or the iPhone? Or pretty much any new product? The buzz was palpable; the hype almost always justified. For years and years, Apple constantly innovated, whether it was with entirely new product lines or updates to existing ones, but recently everything has just felt a little… well, meh, hasn’t it?

Could this feeling because Apple is now so ubiquitous, no longer the underdog? Possibly. And could this be down to some very shrewd business decisions, with Apple deciding to refine and hone rather than experiment, as evidenced by the longer life cycles of designs for their phones and computers? Very likely.

But that doesn’t excuse recent product launches that have (again, in my opinion) fallen flat by their past standards. The MacBook? Well, it’s a lovely little machine (and I’m typing on it right now) and I even took a whole set of photos to capture its beautiful form, but time has revealed it to be irritating in many ways (the keys repeatedly get stuck, for instance, and the removal of a magnetic power connector is genuinely irritating). The Apple Watch? After the initial magic wore off, I came to the conclusion that it’s essentially useless — as did almost every other Apple Watch owner I’ve spoken to. The new Apple TV? A total lack of innovation — both from its previous version and the numerous offerings from competitors. New iPhones aren’t even exciting anymore.

In many ways, I wonder if this all started with the launch of iOS 7: although I was originally one of its supporters when it came out and enraged half the Apple-buying world, when I think about it these days, iOS still doesn’t really encourage interaction. It’s not about flat design versus skeuomorphic design; it’s more about how Apple laid the groundwork for what a great, minimal, mobile operating system could be… and then never really built upon those foundations. The same could be said of their camera technology. The iPhone camera’s noise reduction algorithm has ruined many a photo that would have benefitted from not being put through a paint-like Photoshop filter. Oh, and don’t even get me started on Apple Music. What a mess. Sure, it’s not a total failure from an interaction design point of view, but it’s a sub-par effort from a company that should really be far, far, far better than any other steaming music competitors. That Apple Music has been so successful is only down to the ecosystem they’ve cultivated — not because it offers a superior experience.

Then there’s just all the douche moves Apple has made again and again with proprietary connections — their decision to remove the headphone jack on the forthcoming new iPhone being the latest. All of this has added up to make even this most ardent of Apple fanboys start to question his allegiances.

And all the while this has been going on, Google — which, with each new product launch, whether software or hardware, has become even more of an Apple competitor — has continued to innovate; to make better versions of Apple’s own apps. (I don’t even need to mention Maps, do I? No? Good.) And from a design perspective, Google has well and truly grown up: Material Design offered a lot of promise when it was first announced, and in the time that’s passed since, it’s proven itself to be a strong framework for unifying a the company’s multiple software offerings. Sure, there are times when its incarnation feels a little templated and dry — Google Play Music, for example — and perhaps it’s easy to praise Google for their grown-up new looks when, until recent times, Google web apps were so damn ugly. (Remember how Gmail used to look? For a reminder of that less graceful era, look at the browser version of Google Calendar.) But the difficulty of creating a system that works in so many instances, both in terms of aesthetics and interaction, should not be underestimated.

Beneath all of these apps and interactions and aesthetics, there’s another layer of Google that has become so trusted: its infrastructure. Yes, I get the fears about our data being mined to show us more relevant ads, but who do I trust for reliable cloud syncing: Apple or Google? Who do I trust to backup and share my photo library: Apple or Google? Whose infrastructure do I trust for my emails, documents, calendars, and more: Apple or Google? Granted, the latter could be any service provider vs. Google, but the point is that Google’s infrastructure underpins so much of the internet and our daily lives, it often just doesn’t make sense to let someone else handle what we know Google can handle so well.

(At this point, i’m going to refrain from delving into lengthy praises of particular Google apps and services, but I do want to give a quick mention to the Google Calendar and Google Photos iOS apps. They’re so radically superior to Apple’s equivalents, I’d question anyone’s need to ever open those defaults again.)

All this is to say: if Google can be this good on a competitor’s operating system, how much better can it be in its own environment? This is the question that’s been gaining traction in my head recently.

Android used to be a poor man’s iOS, but it’s obviously grown a lot since then. Unfortunately, fragmentation is a problem that’s plagued Android from the very beginning and is probably the primary factor that’s never allowed me to take switching seriously, but here’s where it gets interesting: with Google making (via OEMs) its own Nexus hardware, it’s possible to use a vanilla version of Android, free of bloat from carrier-installed software. It also removes that weird you-can-only-use-this-particlar-version-of-Android thing that plagues Android phones made by other manufacturers, and, in doing so, puts Google on an evening playing field with Apple: control the hardware and you control the software.It just works.

So it’s this vision of Android — a Google phone in its purest form — that’s making me, and others, consider the switch. And with new Nexus phones rumoured to land (or at least be announced) very soon, the opportunity to do so might be just around the corner.

Or maybe not. The new iPhone is also due very soon. Maybe it’ll be amazing. Maybe it’ll be the best hardware and software combination that exists in the world. Maybe Apple’s core apps, services, and experiences that underpin the entire iOS / macOS / tvOS ecosystem will up their respective games and I’ll look back on this post as blasphemy.

But — sadly — I’m not sure that’s something the Apple of 2016 is capable of.

Next Story — Today’s Vagenda
Currently Reading - Today’s Vagenda

Today’s Vagenda

Ready for the day.

6:00 am. Arise. Wrap your cardigan-sheathed hands around a mug of hot cardamom lemon water; squint into the distance from your craftsman veranda. Breathe authentically. Pick off a passing man with your bespoke porch rifle.

6:30 am. Laundry. The heather-gray linen kitchen towels from last night’s festivities need washing. Delicate cycle; honeysuckle gentle wash detergent. Head back upstairs. Roll up your husband’s body inside the flokati rug upon which it rests. Dust surrounding area with small-batch microfiber.

7:30 am. Morning e-mails. Remind the others about this weekend’s dick-burning.

8:15 am. Breakfast: coconut-ginger scones with raw wolf meat. Using the giraffe filter on Snapchat, falsely accuse a man of rape.

9:00 am. Nap.

9:18 am. Yoga while watching latest Real Housewives of New Jersey; question Jacqueline’s motives. Move the rug-swaddled corpse to a dumpster behind Whole Foods. Buy chia seeds in bulk.

11:30 am. Back home. Shower; wash face with homemade semen-cucumber scrub. Triple steam vulva. Check internet. Mob formed yet?

1:30 pm. Doctor’s appointment — ask about ‘pleasure abortions.’ Do they do group packages? Alison’s birthday is coming up.

2:55 pm. Retail therapy; there’s a sale at Michael’s. Purchase 37 mason jars. Text Jenny for her scrotum-infused kombucha recipe. Commit vehicular manocide in the parking lot. Text while driving; tell the internet mob they can stop — you’ve just killed the man you falsely accused of rape.

4:30 pm. Kill a football team.

4:45 pm. Nap.

6:30 pm. Order artisanal pizza. Abduct the delivery guy upon his arrival; make him dance for you while you work on screenplay for an all-female Saving Private Ryan.

7:30 pm. Google cyanide. Ethically harvested version available?

7:45 pm. Nag a man to death at the local bar.

9:25 pm. Deactivate bitch shield.

9:30 pm. Apply lavender oil to temples, crawl into bed. Snuggle under your hemp percale sheets; set your noise machine to “crickets+men crying.” Fall asleep censoring male speech online.

Next Story — The State Of JavaScript: Front-End Frameworks
Currently Reading - The State Of JavaScript: Front-End Frameworks

The State Of JavaScript: Front-End Frameworks

A few preliminary results

I’ve been very impressed with the success of my State Of JavaScript survey so far. After barely three days, the survey already has over 3000 responses. So I thought it’d be interesting to see what preliminary insights we can extract from that data.

I say “preliminary” because I‘m hoping a lot more developers end up filling out the survey. Not so much to get a bigger-sized sample, but to get a more representative one. After all, these kind of survey tend to reach a population of early adopters first, and that can easily skew the results.

Incidentally, this is also why I didn’t try to advertise the survey to Discover Meteor readers. If I had, Meteor might very well ended up as number one in all categories!

So with this in mind, let’s see what the data tells us!

The Contenders

In this first look, we’ll focus on front-end frameworks. The six choices were:

Obviously this list is not complete, but I decided from the start to try and keep the survey’s length down even at the cost of being less exhaustive.

I did also provide an “other” option asking people to provide any additional frameworks I might’ve missed (more on that later).

For each framework, people could pick one of the following answers:

  • I’ve never heard of it
  • I’ve heard of it, and would like to learn it
  • I’ve heard of it, and am not interested
  • I’ve used it before, and would use it again
  • I’ve used it before, and would not use it again


The first thing I wanted to figure out was how many people were aware of their various options. I’m sure (almost) everybody had heard about React and Angular, but what about Vue and Ember?

No need for a complex chart here, awareness was above 97% for every option except Vue, which had “only” 77%.

It will be interesting to see if these results change as more people take the survey, but for now at least it seems clear that apart from newcomer Vue, front-end frameworks don’t really suffer from lack of awareness.


The second thing I wanted to figure out was what image people had of the frameworks they didn’t use: which one did they want to learn, and which ones failed to generate interest?

As expected, React takes the lead. It certainly seems like everybody and their dog wants to learn React these days (on that subject I recommend the excellent React for Beginners class, and you can get $10 off with coupon code METEOR).

The surprise for me was Vue. Not as many people might’ve heard about it, but those who have must’ve heard good things, because it’s even more popular than Angular 2.

And speaking of Angular, few people want to learn version one anymore. But I didn’t expect Ember’s percentage to be equally low. Maybe a sign that the trend is going towards lighter-weight, single-purpose libraries?


Finally, I wanted to know how happy people were with the frameworks they had used.

This would seem to confirm that React and Vue are not all hype: they genuinely provide good developer experiences.

You’ll notice I didn’t ask how many people were actually using each framework. Part of it is because I wanted to cut down the survey’s length, but it’s also because I’m not sure how useful raw usage stats would be.

For example, I’m willing to bet Angular’s market share is still huge, but would that be reason enough to pick it for your next project, especially knowing that 56% of Angular developers wouldn’t want to use it again?

Other Frameworks

Like I said, my list of frameworks wasn’t intended to be exhaustive, and I was curious to see which other frameworks people would suggest.

As you can see, many people mentioned Aurelia, which took me by surprise as I know very little about it.

Quite a few people also mentioned either Meteor (or Blaze, Meteor’s built-in front-end framework), which I had left out of the front-end section since it was already included in the “Full Stack” part of the survey.

Knockout seems to still be relatively popular despite its age, as is Cycle, which I’m also pretty unfamiliar with. And I seem to remember Polymer getting a lot of hype when it came out, but it was mentioned fairly rarely.

Other observations: the Riot people generally seemed pretty positive about it (“Riot.js — Absolutely will use it again”), and Mithril’s complex spelling might be the reason it’s not higher up in the rankings.

Also there’s apparently a thing called Choo now? Protip: if you want to anticipate 2030’s hottest baby name trends, look at JavaScript frameworks!


My main goal with this survey was to make it easier for developers to decide which frameworks to learn and use.

Based on the current data, I think it’s safe to say that you can’t really go wrong with React, since it’s extremely widespread and has an above-90% satisfaction percentage. And although currently much smaller, Vue also seems like a good bet.

Finally, these results only represent a tiny fraction of the data I accumulated, so stay tuned for more observations and insights coming very soon!

Help Spread the Word

As I said, the more developers take the survey, the better the data will be.

So please help spread the word if you can by sharing, emailing, or retweeting. It’ll be worth it!

Sign up to continue reading what matters most to you

Great stories deserve a great audience

Continue reading