Nathan Dintenfass

Agile for Executives

March 31, 2014 By Nathan Dintenfass

Often when we work with product and engineering teams to improve their processes we also end up talking with executives that aren’t directly involved in building the product. Of course, products are not built in a black box — you cannot adopt the good thinking that has gone into Agile practices without having organizational buy-in. But many product teams struggle to get executives to see Agile thinking as more than just an engineering practice.

We put together a short presentation hitting some of the key tenets of Agile specifically for a non-engineering, non-product audience. The presentation has been well received, so we’re sharing it here in case it’s helpful for your organization.

Deconstructing Agile Part 1: The Language of Agile is Broken

March 19, 2014 By Nathan Dintenfass

The vocabulary of Agile does more harm than good. In helping companies adopt Agile methods we find we need to correct mistaken impressions people have gotten from Agile literature. Our first task is often to help them unlearn unhelpful language so that they can set the right goals and get buy-in from teams. As George Orwell wrote in his famous essay, “Politics and the English Language,” “language can also corrupt thought. A bad usage can spread by tradition and imitation even among people who should and do know better.” Perhaps Agile is dead, but in any case it’s definitely time for a new product development vernacular.

Teams that are new to Agile are particularly susceptible to flaws in the lexicon, often getting the wrong impressions about why these practices might help them. We’ve seen teams go from openly hostile to embracing Agile practices when we get them past the literal meaning of the words, so let’s stop needing to explain so hard and start getting a better set of words to use.

The worst words we use…

“Sprint”

A sprint implies a furious run as fast as you can over a short distance, after which you are out of breath, sweaty, and generally spent. Agile is supposed to be the opposite of that. We want a regular rhythm – not death marches to hit arbitrary deadlines, not idle time waiting for monolithic product requirements documents to get finished. Many teams want “going agile” to make them faster – a goal that is counterproductive and ultimately damaging to success. The theme of speed is woven throughout the Agile lexicon, and it has not served product people well. The language should imply doing work on a regular cadence in intervals short enough to allow for confidence in estimating what we can get done but long enough to allow for meaningful progress in each cycle. I prefer words like “cycle” or “interval” or “period” or “stretch” (I don’t care for “iteration” because it often implies for too many people that we will only ever make small changes).

“Velocity”

In an ideal world teams are relatively stable from cycle to cycle and have a consistent level of productivity. The point of velocity is to give us a reflection of the amount of work we can expect to produce as a team over a known period, so it’s seductive. But teams are rarely ideally configured, and how many points we get done can vary widely. Even when we are producing at a consistent pace the implication is still that we’re measuring speed, and it’s hard to resist the temptation to want to go “faster,” especially since we’re measuring our velocity with a number (assuming we’re using story points).

Velocity, as a quantifiable measure of productivity, is destructive to the goals most teams set out with in changing their processes. Managers tend to want to increase velocity by doing things like giving bonuses for getting more story points done. That attitude is profoundly misguided, not least because of the obvious corruption of incentives when teams are given reasons to inflate points or otherwise come up with a larger aggregate number for its own sake. What we actually want is frank assessments of relative difficulty in order to accurately and confidently gauge what we can get done in a given cycle. When velocity is corrupted to be something other than a means to achieve decent estimates (and thus commitments) it has a net-negative impact on producing good software.

I much prefer words like “capacity” or “load” that get us away from thinking about speed and the sensation of hurtling to the finish line and towards thinking about how we can do our own reality check on the work we commit to do.

“Backlog”

Backlog isn’t nearly as bad as sprint or velocity, but it isn’t great. The biggest problem is that in other parts of life we don’t want backlogs – the word implies things that are piling up, undone. It implies chores you have been putting off, things that stress you out because they are backed up. Constipated. We don’t have a “backlog” in any other domain that we are looking forward to tackling, so why use that word in our work? How about “pipeline”? We like to have a healthy pipeline of things. Or perhaps “slate” or even the very broad “board” as a more general list of things we’re currently focused on.

“Story”

The formal structure of common templates for user stories can be very useful. We’ve seen lots of people embrace the “As a… I want to… So that…” model with good results. That said, we’ve also seen a lot of product managers get very hung up on trying to write a “story” because that word implies a lot of structure and skill, not to mention just sheer word count. We would prefer the artifact use as few words as needed, and we find that over time teams start to find the formal structure to be cumbersome. If we have developed short-hands through conversations, that’s exactly what we want, and feeling pressure to make each line item a “story” with a narrative structure can be counter-productive. Call me old-fashioned, but I think “ticket” works well because it’s fairly general, cognitively allowing for a wide range of granularity. Some might prefer “feature” as distinct from bugs or tasks.

“Scrum Master”

The role of Scrum Master is the most problematic for organizations making a transition to Agile processes. Much of the difficulty has nothing to do with the name, but the name does carry unnecessary baggage into the discussion of what a Scrum Master does and why they are good to have. As a role that isn’t directly responsible for making something concrete, many managers who would otherwise be enthusiastic about Agile are loathe to pay for someone to “just” run sprint rituals. That resistance is exacerbated by confusion about the power (or lack thereof) that person will hold by virtue of the title “master.” Sometimes the best people to play this role are actually up-and-coming engineers who are eager to better understand Agile methods and take on a leadership role. “Coach” or “captain” can help frame the role better in the minds of managers and team members.

“Agile”

Finally we come to the name of the entire discipline. Once again we are faced with speed-based thinking, and once again we endanger the success of our process by focusing on the wrong thing. We’re right back to setting the wrong expectations that we’ll be magically faster and cheaper. It’s nice to have a named set of tenets, but the reality is that teams have specific and distinct challenges and constraints. Rarely should we implement a pure version of any of the flavors of Agile practices. It has become increasingly common to see long-time advocates for Agile practices become disillusioned with what “Agile” has come to mean.

In our consulting work we focus on tailoring the recommended changes to the specific team and the goals they have. Usually we end up focusing on being more adaptive and responsive or on shortening the distance between ideas and manifestation of those ideas (both in terms of communication and elapsed time). A process well-matched to a team should be derived by that team based on first principles that come from introspective self-awareness by that team.

In summary, here’s a mapping of some suggested changes to the vernacular, in rough order of my preference.

Agile → Responsive; Humanized

Sprint → Cycle; Interval; Period

Velocity → Capacity; Throughput

Backlog → Pipeline; Slate

Story → Ticket; Feature; Token

Scrum Master → Coach; Captain

The age of holistic product development

September 9, 2013 By Nathan Dintenfass

Over the last decade a few major themes have dominated the evolution of product development, particularly software development: a shift towards agile practices, customer-centric decision-making, and better integration and collaboration across disciplines. The last of those – the increasing porousness between the “Big Three” disciplines of product management, design, and engineering – is evolving the most rapidly. The tenets of Agile development are fairly mature at this point. Customer development and Lean practices are now considered conventional wisdom. But the ways in which designers, product managers, and engineers work together are in flux. The boundaries between the Big Three pillars of product development are just beginning to blur.

Design has changed the most dramatically and had the most significant impact on engineering and product management. A decade ago design was little more than static mockups or graphic treatments of engineering output. Today, not only is design key to creating successful products at all stages of the lifecycle, it has also become a viable strategic differentiator for the companies that do it best. Design as a discipline has always encompassed more than just the façade (the “chrome” as we called it before Google appropriated the word). In software, however, only recently has design been acknowledged as a major strategic input. Product managers are the voice of the customers, but designers are the voice of the humans.

Designers in software have also become more rigorous and technically proficient. A shiny mockup that gives a good first impression was all a good designer used to have to make. Today we expect the design process to start from a clear set of first principles derived from a deep understanding of the people using the product. We expect designers to understand information architecture and to create a consistent, reasoned visual vocabulary and a sensible flow. We expect designers to intimately understand the capabilities of the technologies used to implement their ideas, and increasingly we see designers with substantial software development experience working with the same tools as engineers.

The evolution of design has impacted product managers and engineers as well. Product managers are now expected to understand and utilize design thinking. Engineers need to be conversant in the design vernacular and are becoming increasingly skilled in basic design principles. These cross-pollinations are a healthy development, and as the last vestiges of linear, waterfall-style processes fall away, teams are looking for ways to integrate their efforts and break free of assembly-line metaphors (GANTT charts are not exactly in fashion in software development). Classic Scrum orthodoxy has also left teams looking to loosen the bottleneck created by a single Product Owner who must be the conduit between the entire business and the Team. At the previous two Products Are Hard conferences, for example, we saw a great deal of interest in talks about ways to better integrate designers into the development process.

We use the world “holistic” to describe this evolving approach because of the convergence of disciplines, processes, and strategies that are all based on integrating across disciplinary boundaries. Designers, product managers, and engineers are influencing each other and are working more closely than ever before. We have built new processes to favor responsiveness and experimentation over predictability and certainty. We have pushed our business strategy to be more informed and harmonized with the human needs and desires of those we build for.

We’re curious about your experiences. Are you seeing a similar trend? Different trends? Let us know: @productsarehard

Text trumps video for remote teams

June 7, 2013 By Nathan Dintenfass

Over the last few years we’ve done a fair amount of work with remote development teams. One of our current clients is going through a company-wide transition from waterfall to agile, and they use remote contractors extensively. A primary goal of the transition is to make better use of the full talents of their engineering team, so good communication is essential.

When working with remote teams, it’s tempting to try to replicate the experience of an in-person meeting. Google Hangouts make the features of much more expensive teleconferencing products available to a wider audience, and increasingly we see companies set up their conference rooms with large monitors hooked up to a simple webcam to use Hangouts or Skype.

The aforementioned client uses Google Hangouts as a matter of course for all interaction with engineers, putting heavy emphasis on video conferencing in an attempt to make the remote developers feel more a part of what’s going on. In sharp contrast, a different client holds their morning stand-up meetings exclusively on IRC (even when they’re all in the same building) – old-school, text-only group chat.

Text works better in most cases.

The simple truth is this: giving a meeting your full attention is hard enough, but giving a meeting your full attention when you’re attending remotely is impossible. This is particularly true when you’re a remote software engineer and the topic is something other than the particular bit of code you’re working on. Remote developers are not going to give their full attention for the entire duration of a meeting. It’s not the way our brains work.

Three more concrete reasons we prefer text-based remote discussions:

A text-based conversation is much more forgiving of momentary distractions. If I zone out of the discussion for a minute while I answer an email I can quickly catch back up by reading the transcript.
A text-based conversation ensures everyone gets their ideas in. In a voice/video conference it can be difficult to know when there’s an appropriate pause in the conversation to interject. When an engineer in Bulgaria is trying to provide input to a conversation happening in a room in Mountain View, they need a way to interject without having to force their way in.
A text-based conversation can be reviewed later. If someone misses a meeting or arrives late, or if you need to refer back to the discussion after the fact, a text-based conversation is there waiting for you. This also frees everyone from needing to scribble notes furiously while the meeting is in progress

Video and voice have their place. One-on-one or small group chats can benefit from the immediacy of video. If the remote party is leading the conversation or presenting it can also be beneficial for everyone to see that person. If people are not expected to participate and just listen it can be nice to be able to hear and/or see the person presenting rather than needing to read. Text works well when a group of people all need to participate.

Google Hangouts can serve both purposes as it has text-based chat is built right in. IRC is the classic text-based chat, though modern products like Campfire, HipChat, and other online collaboration tools are more manageable if you don’t already have IRC set up (built in logging, image rendering, file uploads, etc. are some obvious features IRC doesn’t offer easily).

PAH13 wrap-up

April 9, 2013 By Nathan Dintenfass

PAH13 is in the books. By all measures it was a success. Thanks to the over 200 people (30% more than PAH12) who made it a great day. Early feedback has been overwhelmingly positive. Particularly encouraging was how many teams came together, and we had multiple people say they wish they’d brought the people they work with every day. Next year we will put more even more focus on making it valuable for teams to attend.

After PAH12 we wrote a postmortem on our first attempt, and this year we definitely felt like we’d made it up the learning curve quite a ways. It helped that we did it at the same venue, though we filled the room, so we’ll need to decide if PAH14 can fit in that space.

Below are links to the slides from the speakers along with any supplemental links the speakers provided us. Also, Carolyn Wales has agreed to let us post her personal notes from each talk (along with delightful little sketches of each speaker).

Thanks again to our lead sponsor, GitHub, along with Klout, Zendesk, Pivotal Labs, and Chirrpy.

We will update this post if we receive additional supplemental materials and/or when we get audio/video of the talks.

If you have any feedback we’d love to hear it. Get in touch!

Be sure to follow us on Twitter (@productsarehard) for updates on future PAH events.

JANICE FRASER

SONNY VU

SARAH ROSE

DAVE CHARRON

CHARLES HUDSON

HITEN SHAH

SUE BETHANIS

JUDD ANTIN

INDI YOUNG

IAN KENNEDY

CHRIS LINDLAND

The five pillars of product management

March 11, 2013 By Nathan Dintenfass

A few years ago, as I prepared to leave a product manager position, I trained a junior member of the team, someone new to the role of product management, as my replacement. I told him the role comes down to the following five elements.

Gather

A huge part of product management is simply knowing what’s going on — what people do all day as it relates to the product, what kinds of things they wish they could change, and how the various constituencies interact. While most product managers have plenty of good ideas on how to improve the product, gathering ideas from and identifying problems in the rest of the organization are just as important.

Synthesize

As ideas and issues emerge, a product manager must create connections where others do not see them. Two groups in an organization may have two very different problems. A product manager should be able to find a way to make a single, better-abstracted view of the underlying concern. Synthesizing also involves creating named themes, initiatives, and goals for a product. Never underestimate the power of synthesis to create common understanding and bring sanity to the chaos of “line item” requests. Synthesis is also instrumental in winning the hearts of product team members.

Prioritize

Choosing what is most important is an art. Deep understanding of business strategy, market realities, and resource capabilities is key. Knowing what’s hard vs. what’s easy and what’s of broad vs. narrow value helps to create a prioritized list of the various tasks to be completed. Given infinite time and infinite resources everything would be possible, but in the real world, making the hard choices (or, more importantly, helping the rest of the organization make the hard choices) becomes one of the central functions of a good product manager.

Define

A product manager must own the detailed definition of what the product should do so that engineering knows what they will build. This involves plenty of documentation, though much less than you probably think. Document only as much as you have to. Don’t create detail for detail’s sake. With web-based software the need to be quick and iterate frequently makes it essential to move forward with imperfect information and adjust as you go. If you’ve been an engineer or worked closely with engineers, you know the unique horrors of changing the spec and the dread of feature-creep. Part of the reason for the rise of agile methods is that rather than constantly reacting to attempts to get to a “finished” spec of a project (only to see that spec change in the middle of the cycle) engineers started to simply build the dynamic nature of requirements into the system. “Define” does not always mean writing down as much as being the Source of Truth.

Shepherd

A big part of my day as a product manager involves, quite literally, walking around the building. Keeping all of the balls in the air is a critical part of product management. In most organizations there is nobody else who sees all the various pieces and how they must fit together. Many product efforts require coordinating distributed efforts towards a single destination (and doing that over and over again). In my world, having the engineering “done” is only about 2/3 of the process. Once the actual “product” is at a finished state, packaging, documenting, training, and distributing all remain.

When I first put these 5 elements on a white board I wrote the word “CONTEXT” next to them. Ultimately, you must undertake all of these activities with a full appreciation for the business as a whole — the goals, strategies, capabilities, culture, and, most importantly, the people.

Product is a curious function. It is often under-appreciated, yet it is also the domain of some of the most powerful people in Silicon Valley. Product people must be generalists while also obsessing about small details. They must cross cultures within their organizations. They must be able to step outside the organization and sit on the same side of the table as the people for whom the product is made. It’s a hard, rewarding job and it’s the glue that holds many great organizations together.

Choosing a technology is choosing a culture

February 27, 2013 By Nathan Dintenfass

Which technology is best to use in launching a new site or web application? There was a time when I would answer this question by getting into the details of the various features and performance characteristics of a given platform, but over the years I’ve realized it’s really not a technology question; it’s a people question.

The issues are: who is going to build it, and who are you going to want to hire to continue to build it. Anyone who has been around software engineers (or any engineers) knows that a truly great engineer is worth many mediocre engineers, so if you’re starting a technology-intensive business, it’s critical that you be able to attract high caliber people. For instance, Adobe ColdFusion (formerly Macromedia ColdFusion, formerly Allaire ColdFusion) is an extremely productive platform for building web applications — in terms of getting something done quickly it’s great, but good luck finding great engineers who want to work with ColdFusion. Deserved or not, ColdFusion has a reputation in the industry for not being a “real” programming environment (there’s a whole other discussion to be had about the perversely inverse relationship between the ease-of-use and productivity of a programming environment and the credibility it receives in engineering communities). Most software developers wouldn’t want to be forced to work with ColdFusion for fear their other skills would atrophy. This is not a statement about how good ColdFusion is as a technology; it is a statement about the realities of putting together a team.

This is a nuance lost on a lot of entrepreneurs and managers who haven’t done hands-on coding before — the tools you choose define the nature of the team you will build moving forward, and in most cases it’s extremely difficult to switch gears. To be fair, this nuance is also usually lost on engineers, who can easily burn a lot of cycles debating the merits of Ruby vs. PHP vs. Java vs. ColdFusion vs. every other thing. In the end, the tools listed here, among many others, are mature enough that they can all serve well to create web-based applications. Some might take longer, some might not scale as readily, some might not integrate with other technologies as easily, but from the standpoint of “can it be built in a reasonable amount of time and be production-ready and reasonably scalable” the answer is yes in all cases. The best technology to choose is the one that creates the culture you want.

Conferences are hard

May 8, 2012 By Nathan Dintenfass

Having had a week to recover from our first Products Are Hard conference, here are a few lessons learned. Not all of these lessons are generalizable, but giving a flavor for the behind-the-scenes is true to the spirit of the event. In no particular order:

Cash flow can be tricky.
When using Eventbrite you don’t actually get the money from ticket sales until 5 business days AFTER your event is over, but, of course, you need money up front to secure the venue, food, A/V, etc. If you don’t have a giant pool of cash hanging around this can create a sticky situation. We were able to cover the financing, but in talking to others we find people can be surprised by this issue when planning their first event. There are alternative registration systems that will let you get at the money before the event is over, but that generally requires setting up your own merchant account to process credit cards.
Costs
The cost of putting on an event can vary quite a bit. Food is typically the biggest variable cost as x feeding people a meal is much less than $25 a head (and often considerably more). The venue, in general, is the largest fixed cost. Once you get above 100 people there are only so many venues that can work at all, and above 200 people puts you (at least in San Francisco) into another pricing tier. Most of the venues that the tech community uses in San Francisco that hold ~150-300 people run $4K-$8K (some even more) for a day. A/V rental varies depending on the level of production value you’re going for. We rented A/V equipment and staffed it with our own people, so it was a minor part of the overall cost, but if you want highly professional A/V that is run by professional staff you could be looking at $10K just for that.
The Venue
We really love the room at the Hotel Whitcomb and find the hotel to be charming. That said, some people felt the neighborhood was sketchy and are more used to shinier digs for professional events. You can’t please everyone. The other nice thing about the Whitcomb is they require a very small deposit up front and don’t charge extra for tables and linens, though you do have to use their catering for all food and drink, so you have limited flexibility on that front (but their prices are fairly reasonable). We had a great experience working with the Whitcomb staff. They were accommodating to our last-minute changes and didn’t nickel and dime us.
Details, Details, Details…
As with any product the details make all the difference in a conference. There are so many little things that come together to make the entire day coherent and as first-timers we missed some and had to scramble with others. Thankfully we had a great muse to help us out who had been there, done that. Just a couple of the many little details were printing the schedule on the back of the name badges and putting the Twitter hash tag on as many slides/surfaces as possible.
Pricing
Our pricing was $299 for early bird and $399 for regular admission. We were told repeatedly that our pricing was “very reasonable” which we took to mean we could probably charge $100 more next time and still not be considered “expensive.” From what we heard, almost nobody chose to not come due to price, which for a first-time event is great. Of course, there are classic supply and demand dynamics at play here. If the event becomes so popular that it sells out in a matter of days our pricing likely won’t be so “very reasonable” next time.
Marketing
We tried a lot of different ways to get the word out about our event. We spent $1K on LinkedIn ads that targeted only people with a specific set of job titles that are in San Francisco. We spent a few hundred dollars on Facebook ads targeted similarly. We spent a couple days filling out all the various forms on event calendar sites. We paid a couple bloggers for ad space. We reached out to many more bloggers to write about us (some did). In the end, we can attribute only a small percentage of our ticket sales to any of those approaches. What did work? Twitter. We asked all of our speakers to tweet about speaking at the event (and gave each of them a custom discount code). We used Buffer to queue tweets that mentioned our speakers (some of them RT’d us when we did that). We mentioned people we think are just interesting product thinkers in our tweets. We gave lots of our friends custom discount codes and asked them to tweet about it. We did similar things on Facebook, but from what we can tell Twitter dwarfed Facebook in terms of influencing actual purchases of tickets. We also sold many of the seats through direct invitations sent to our friends and former colleagues (all of whom received a custom discount code that, in some cases, brought whole teams from their companies). Not shockingly, it took many tries to get some folks to actually register for a ticket, and in most cases we were thanked for the reminders. If you’re not a natural marketer it can feel uncomfortable to be “spamming” your friends and colleagues, but our mantra was that if you don’t feel like you’re being annoying you are doing it wrong. We found the old adages are true that people need to be exposed many times before they buy, so when in doubt you just need to pummel every avenue you can think of to get the word out. Our hope is that next year we’ll be able to start with the attendees from this year, which should get us a critical mass of tickets sold.
Speakers and Panels
We received a lot of very positive feedback about the speakers at the event. The keynote addresses both got rave reviews. People were less crazy about the format of the panels, though, interestingly, we had some people love some of them and others hate those same ones (and vice versa). Next year we will likely scrap the panel format and either do all individual speakers or set up a more engaging multi-party encounter. We’re toying with the notion of setting up a debate-style format where two people are cast on opposite sides of an issue up front. Overall, we felt like the pacing of the day was good. Some speakers could have happily used a bit more time, but as they say, “leave ’em wanting more.” We have also talked a bit about mixing up the day more to have some kind of hands-on workshops or other breakout sessions alongside the speakers, but that creates a much more complicated set of logistics and is in many ways harder to make good.
Just Do It
We had talked about doing an event like Products Are Hard for over a year before pulling the trigger. It took an enormous amount of time and emotional energy. Putting on the event was very satisfying, and once we decided to do it we pulled it together very quickly (8 weeks elapsed between our first emails to people to feel out the idea and people taking their seats at the conference). The first time you do an event is always the hardest (or so they tell us), so if you have a great idea for one don’t keep putting it off.

If you want to hear about our 2013 conference the best way is to follow @productsarehard on Twitter.

Strategy and negative space

February 9, 2012 By Nathan Dintenfass

Negative Space

“Keep your options open,” my mom used to say to me. Perhaps that’s good advice for a 12-year-old, but it’s terrible advice for your new business/product. Every company wants a strong strategy, a strong brand, and loyal customers. Ask a room full of decision makers if they want a clear positioning with their target market and you won’t get many saying no. If you press them to abandon some options and stand for something specific in the minds of their customers, the conversation gets awkward.

It’s easy to spend a lot time coming up with good ways to describe what we are — we can talk to potential customers about their needs, we can fuss with marketing copy ad nauseam, and we can generally convince ourselves that the path we are choosing is correct.

The most powerful way to carve out a strong position in a market is to choose what you will NOT be. And I don’t just mean making a mealy 2×2 in which you are “high-high” on some rigged axes. No, the essence of good positioning is to choose the thing you won’t pursue that will be a good option for someone else.

In some cases this is as simple as positioning against an existing competitor. In most cases it will take hard decisions because the human instinct is usually to keep your options open. These decisions aren’t irrevocable, but they do require a commitment from you and your team. So commit, and don’t listen to my mother (in this case).

Mobile app vs. mobile web

February 1, 2012 By Nathan Dintenfass

We’re often asked about the relative merits of building a native mobile app versus spending the energy on a mobile-specific version of a web site. This question is most relevant when the content of the app is similar to an existing web site, but the situation comes up often.

The case for native apps

We find that iOS remains the dominant app market, so some of these points are specific to that platform.

Idiom – The difference between a native app and a mobile-optimized web experience can be closer than they used to be (Facebook is a good example of this), but it will always be hard to replicate truly idiomatic device-specific experiences smoothly with a browser. These differences can be very subtle, but they can be critical to how often people will want to use the application, how they will feel while using the application, and what they can accomplish with the application.
Intimacy – The Web is a big place, and the web browser is a generic tool that people use for all aspects of their online lives. Our phones are intimate. They go everywhere with us every day. The apps we have on our phones are part of that intimacy; they are a set of symbols that represent our interests, chosen specifically and intentionally. Once your app is on the phone it becomes, in a small way, part of someone’s identity. A website, however beautiful on the phone, doesn’t have that kind of relationship.
Push Notifications – Push notifications give your communications an immediacy and urgency – this can be easily abused, but a web site will never be able to create that kind of intimate call to action.
Badges – The little red numbers that appear in the corner of an app’s icon when something new is available – these are really a sub-type of push notification, but the experience is different enough that it’s worth thinking of them as separate tools. Badges provide a gentle way to urge your users back into the app.
“Home Screen” Exposure – When your brand identity is on the home screen day after day it’s a constant reminder that you exist. Sure, it’s possible for someone to add an icon representing your web site to their home screen, but that’s relatively rare behavior.
Connectivity – Local storage has made it feasible to use a web app when the network is not available, but most web apps will require network access. Network coverage is improving, but anyone who uses a mobile device still regularly encounters dead zones. Network connectivity may still be essential even with a native app, but you have more and better options for ways to cache data that needs to be downloaded or uploaded and react when the network becomes available again.

The case for mobile-optimized sites

For the sake of discussion we assume “web” in this context means the kind of browsing experience you get on iOS and modern Android devices (as opposed to trying to build for the “browser” on, say, older Blackberry devices – a task we would not wish on our worst enemies).

Cross-Platform Support – As Android continues to gain market share it’s no longer enough to assume iOS is the only game in town for native apps. While iOS remains dominant in terms of actual humans actually using apps, if you want to reach a broad audience you need to target more than just iPhones and iPads, and the web is one of the best ways to do that.
Avoid App Stores – With web apps you don’t need approval from Apple to roll out a new version of your app, nor do you need to worry about whether people are bothering to upgrade to the latest version. When you deploy a new version you control when that happens and who sees it. This can reduce a lot of headaches in both timing and support.
Talent Leverage – Developing native mobile apps remains an art different from creating web applications. If your business requires both, that means figuring out ways to get your software built with two different teams. While mobile-specific web apps have some eccentricities that are different from “regular” web apps, the skills to build them are not appreciably different. That said, our experience is that most teams still need to expand resources when they get serious about mobile web experiences.
Total Cost of Ownership – In many cases a mobile web app can take advantage of existing code and process for your web app more easily than a native app. As you optimize for life with both a mobile and desktop web app you can build your development and business practices to minimize the distance between the two. For instance, a first version of a mobile web app might be as simple as conditionally loadings a stylesheet (if you’re lucky enough to have a well structured web app in the first place), which is certainly going to be cheaper than building out a satisfying native app. You risk getting what you pay for in this case, but at least you can try out a mobile experience much more easily on the web. That said, if you look at sophisticated mobile-specific web apps it’s likely they require similar resource levels as native apps to create and maintain.

Choosing whether to develop a native app or a mobile-optimized site is further complicated by the evolution of cross-platform tools such as PhoneGap, Titanium, and Trigger.io which allow the use of web technologies inside a native app wrapper. There is relative paucity of high-quality consumer apps built on these platforms, but the rising popularity of Android is forcing more difficult choices about which ecosystem(s) to target, so expect such tools to continue to mature and multiply.