The Mobile Surge

Helping brands thrive in the mobile revolution

[mobilesurge]

How Apple and Google are Helping Cure Humanity’s  Diseases

Apple announced the open-platform medical research tool ResearchKit on April 15, and while it was overshadowed by news of the Apple Watch, it’s a tool with staggering potential for... well… humanity. “We are incredibly confident that [ResearchKit] will have a profound impact on all of us,” Apple CEO Tim Cook said at WWDC in San Francisco. The initial apps released with ResearchKit included apps for asthma, Parkinson’s disease, diabetes, cardiovascular disease, and breast cancer. So how does it work, and why is it important? Is it the future of healthcare research or just a flawed, creepy data collection tool? And what the heck does Google have to do with it?

A new method

With ResearchKit, anyone can participate in a scientific study. Researchers set the criteria and eligibility requirements in their app, and an interested iPhone user then downloads that app and fills out a questionnaire. The app then tells participants what to do. For the Parkinson’s mPower app, for instance, users are asked to speak into their device’s microphone and take several steps, allowing for researchers to track and measure gait to gauge the progression of the disease.

The robust technology of the iPhone and Apple Watch can give researchers never before imagined, real-world data. And the widespread use of the iPhone (and Apple Watch) means an exponential increase in the sample size available. Unlike traditional research, scientists won’t be limited to slow, expensive, and laborious manual recruitment that yields relatively small sample groups. With ResearchKit and programs like it, any approved researcher can collect data on not dozens or hundreds but perhaps millions of people. This massive open access to research subjects and their data is what makes ResearchKit so important.

Just the beginning

But apps are just one aspect of ResearchKit’s ultimate potential. Apple is now expanding into genome territory. Partnering with UCSF and Mount Sinai Hospital, they’re currently recruiting large numbers of participants for a massive genome-sequencing project. So far we don’t know exactly what Apple plans to do with all this information, but there’s immense value in the interaction between your genetic data and your lifestyle data collected by things your phone and watch already track (location, purchasing habits, diet, fitness, and sleep). Combined, these two data could give researchers an unprecedented look at how genetics and environment interact to affect our health.

But it’s not just Apple who wants in on the health game; Google is developing programs right alongside them. In 2014, Google launched the Baseline Study. The project aims to genetically and molecularly map healthy human bodies in a wide population, using the large amount of data identify and track genetic markers that could indicate a propensity for disease. Testing began with bodily fluid collections, and included a full genome study and family history. Future plans include the addition of wearables that could continually collect data and transmit it back to Google.

And now, Google has announced the launch of Study Kit, its answer to ResearchKit. With these two giants both working on health and genetic data collection, we could wind up with literally billions of gene sequences and health profiles from around the world.

Sampling bias? Maybe not.

The inherent problem for Apple, of course, is that no matter how big the ResearchKit numbers, the data will be reflective only of iPhone users. That means by necessity a higher income bracket, among other differentials. The median iPhone user in the US earns $85000, while the median income in the US is $51,939. It’s even been found that, for the most part, iPhone users are better educated (or at least, states with a higher number of college graduates have a higher number if iPhone users).

Why does this matter? Certain health conditions, diet-related cardiovascular disease for instance, overwhelmingly affect poorer populations, making accurate date from iPhone users not that likely. There’s also the issue of self-reporting. Participation will be based on opt-in, with no way to vet any participants beforehand. Dartmouth professor of medicine Lisa Schwartz says, “Unless the study has a standardised way of vetting fundamental information — do the people actually have the disease? — it is a big black box. Trust without vetting is a very weak research design.”

If our fears are that data will be skewed toward the rarefied world of iPhone users, Google’s entrance into the game puts those fears to rest. While iPhones may not be in widespread use in developing nations, Android devices are, and by next year 2 billion people will have smartphones. That’s 2 billion potential test subjects. With Apple dominating the high end of the market, Android is successfully capturing the lower end, providing us the potential data from both the world’s richest and developing nations.

An Android- and iOS-based ResearchKit/Study Kit could cover much of the globe, bringing us information about diseases that affect mostly developed nations like type 2 diabetes to those affecting  developing nations like malaria. Google could reach the next billion in much more significant ways than we thought. Those billion new users could represent a billion new chances for researchers to study health issues the world faces every day.

A staggering candidate pool

The MIT Tech Review wrote, “Apple sold 60 million iPhones in just the first three months of this year, contributing to a total of about 750 million overall. That means DNA studies on the ResearchKit platform could, theoretically, have rapid and immense reach.”

It can’t be denied that both ResearchKit and StudyKit represent a huge step forward. Finding candidates for medical research isn’t an easy thing. Recruitment efforts, though costly and time-consuming, often fail, and the lack of test subjects is a major problem for researchers. “Human clinical trials are critical to improving medical treatments and finding cures for chronic, debilitating diseases, yet less than one percent of those with a given disease participate”, says Parkinson Pipeline Project. “The biggest obstacle to patient participation is lack of awareness about clinical research studies and the role they play in the drug development process.”

It’s not that people are uninterested in participation, but that knowledge that research is happening is so sorely limited. Rutgers found “32% of American adults surveyed indicated they would be very willing to participate in a cancer clinical trial if asked to do so and an additional 38% of adults are inclined to participate in a clinical trial if asked.” It’s getting the studies to the people that’s the hard part.

But with an estimated 470 million iPhones users worldwide and nearly double that many Android users, the pool of candidates just became almost unimaginably large and those studies are potentially in the palms of millions of hands. The volume of potential data is simply staggering. What could we learn from studies whose sample size were in the tens of millions...even billions? We may soon find out.

[mobilesurge]

The Asymmetrical Advantage of Distributed Teams

I’ve talked before about BiTE’s completely distributed team, and how I think this is one of the keys to our success. Not only does it vastly open up the talent pool when looking for new team members but it decreases turnover while increasing productivity and flexibility.

I’m often asked how we deal with the “inherent inefficiencies” of a fully distributed team, which underlies the sad assumption that unless you make the trip into an office every morning, you’re not really working -- you’re slacking off. This just simply isn’t true. But why?

No useless meetings

Everyone has been stuck in an interminable meeting, after dutifully shuffling to the conference room during. Offices seem to breed meetings, and because we are not at our desks the meeting can not be about collaboration but rather a discussion about what has been or needs to be done. We see evident that this is not working in almost every meeting where people are on their laptops or smartphones doing other work. Once a meeting is done everyone heads back to their desks to all start separately working on their tasks. If there’s a question, update or suggestion, we have to use email or the sneakernet to figure stuff out. These meetings waste time, and we’ve found they’re frequently pretty useless.

In our distributed team, meetings are solely for the purposes of collaboration or completing tasks. The tools we use every day (Slack, Google Hangouts, Google Docs) help us solve problems in those meetings, not talk about solving it and then regroup later to discuss the solution.  

The best example is comps and wireframes. In a traditional shop, we’d do a wireframe/comp review provide feedback and wait until the next meeting where the process would repeat. This takes days (sometimes weeks). Mobile needs to move much faster. When we review wires/ comps, we collaborate on a hangout and see our changes being made to the documents in real-time. Not only is it fast (usually accomplishing in 1 or 2 meetings what tooks days/weeks) but it is better. We are able to see what works and what doesn’t immediately. Avoiding rabbit holes and dead ends that are the standard for traditional on site reviews. 

Work better, not longer

With our model, we’re able to work longer on each client’s project without increasing our total work hours. How? Easy. We’re more efficient.

If we get blocked on a task, we message someone in Slack. Need a meeting, we start a hangout. Need to get a surprise RFP or an emergency change to the website done in an hour? There’s no need to book a conference room for a meeting -- start a Google Doc and have the company swarm on it. These tools mean our cross-country teammates can work more closely than people in adjoining cubes.

And what’s the biggest time thief? The commute. According to the US Census, the average commute is just over 25 minutes with larger cities (those where most tech companies need to be to attract key talent)  trends into 45-60 mins each way. With a fully remote team the commute is zero. Nothin’.

The time we save not getting to and from doesn’t just disappear. It’s banked.  We use it. We work longer on each project without having to sacrifice time spent with our families, at the gym, or you know, on our lives. We’re fresher, happier teammates who get more done because we don’t waste 20% of our days commuting. This helps us retain highly sought after resources while delivering more quickly for our clients.

Five years ago, this kind of efficiency wasn’t possible. The tools hadn’t evolved to where we could be just as close from a thousand miles away as we are in the same room. But with the proliferation of cloud-based productivity tools, the ability to work collaboratively and efficiently from anywhere has grown. At this point there’s simply no reason to waste your hard-won revenue on office space.

One more thing: I think I’ve successfully explained why our distributed team works, but I haven’t answered that implied question, “how do you know when people aren’t working?”. Ronald Reagan once said, “Trust but verify.” Our team is amazing and we trust each member, but we do have ways to verify. The very collaboration tools that make it so easy to work together also make it easy to see if one person is dropping the ball. Having connected collaboration tools means everyone can see what everyone is working on -- all the time. Nobody can hide behind these cube walls.

[mobilesurge]

Project Titan: What We Know So Far About the Apple Car

Over the years, speculation over the next Apple product has become a way of life. Entire sites devote themselves to the dissemination of rumors and the aggregation of insider tidbits. Today I’ll pick apart the facts and rumors about the much-talked-about Apple Car. Wait, what? So I’m saying it’ll really happen? Yes, it’ll happen, and probably much sooner than we had thought.

Once upon a time...

Really just this February, an unnamed (unnamed because Apple is locked down stronger than Fort Knox during The Purge,) insider sent an email saying that Apple was working on a project that would, “give Tesla a run for its money”. That led every Apple-obsessed journalist on a hunt for clues, which revealed Apple had hired former Mercedez-Benz R&D head Johann Jungwirth.

Speculation was quick and disparate, with the majority of pundits deciding Apple was just working on an advanced version of CarPlay. Then the Wall Street Journal dropped the knowledge and said Apple had for the past year been working on an electric vehicle. According to WSJ sources, Apple had hundreds of employees working on a minivan-styled vehicle called “Project Titan”. So here’s where you’re allowed to groan. Minivan-style? Really? But I wouldn’t worry. With all the interior space, the minivan makes an excellent prototype but there’s no reason to think the Apple Car will necessarily be a minivan.

More clues

With Project Titan supposedly confirmed by a number of inside sources, the clues came more quickly. Contract manufacturer Magna openly courted Apple and positioned itself as the go-to manufacturer for both Apple’s and Google’s vehicle projects, with its niche-vehicle production facility in Austria at the ready. Why is Magna important? Well, they’re the auto version of Foxconn Technology Group, the China-based manufacturer that assembles iPads, iPhones and other devices for Apple. It’s likely that Apple would employ the same wildly successful outsourced manufacturing process to cars themselves, identifying various key manufacturing partners, locking them down, and freezing competitors out from the supply side.

Speaking of Europe, we also recently watched speculation that the sale of possible Google competitor Nokia’s Here maps could go not to Apple directly but to an automaker in Germany. Now, this doesn’t mean Apple is out of it; we’ve heard rumors of Apple’s mysterious maybe partnership with Tesla, so who’s to say they won’t partner with a European automaker?

Recruitment

Amidst the flurry of stories and posts about the mysterious car, Apple has been quietly amassing a heavy-duty team in Cupertino. With a rumored goal of 1,000 people working on Titan, talents have been poached from A123 Systems, MIT Motorsports, Ogin, Autoliv, Concept Systems, and General Dynamics, as well as auto giants like Tesla, Ford, GM, and Mercedes.

Electric and Autonomous

Pay extra attention to the name A123 Systems; Apple now has five former employees on the payroll, and A123 does one thing -- makes batteries for electric vehicles. So it would seem undeniable that the Apple Car will be electric. By the way, all that poaching didn’t sit well with A123, who in February sued Apple for stealing its employees. But all’s fair in love and tech, and the two are headed toward a settlement now.

So will the Apple car be autonomous? The answer most certainly is “yes.” Apple wouldn’t think of entering the market unless they were going to offer a profoundly innovative new product based on their substantial logistical, design, hardware, and software strengths. Plus, everyone is working on self-driving vehicles, including Google, Uber, Delphi, Audi, Nissan and a host of others. As far back as 2013 Apple hired renowned roboticist John Morrell, so we think autonomous has been on their minds for some time.

The trick will be to make it entirely autonomous, and not driver-assisted. I assure you we do not want driver-assisted cars. Driving can already be a horrible experience already, with distractions, unpredictable motorists and traffic, cyclists, road work, and pedestrians that confuse and confound us. But ‘driver assisted’ just sounds like torture. That sounds like I have to be alert and attentive but a machine will take away the very process of driving that keeps me alert and at least slightly interested. Even though i despise driving, it gives my mind something to do. If you take that away, how will I remain focused?

No, for the Apple Car to be a success it must be fully autonomous for most of a typical trip or it will be worse than manual.

When?

Analysts predict we’ll see the Apple Car in about 2020, which seems like a fair guess. After all, the iPhone was in development about 5 years before its launch, and the Watch a relatively short 3 years. So will you buy an Apple Car? The danger, of course, is that the 1st generation will quickly look as dated and clunky as your first generation iPad, but a car isn’t one of those things you can comfortably replace every two years when a new one comes out. If it really does turn out to be a minivan, all we can hope is that Jony Ive can render a boxy monstrosity an aesthetic masterpiece.

So why is Apple developing a car? 

The automotive market is huge, with almost 74 million cars (projected to be sold worldwide this year. More importantly, the industry is ripe for disruption. All cars are basically made from the same material, designed off the same template, assembled in the same manner, sold, and even maintained in the same manner. And ALL the car companies are doing it the same way. Even Tesla’s only disruptive innovation is not an electric power source build on the exact same drivetrain template but direct sales rather than dealers.

Further, the technology is decidedly inferior with innovation all but stopping. Benoit Jacob, the head of design of the BMW i design was quoted “after nearly a century of development cars have evolved into an almost "perfect" form, which has made it more difficult for manufacturers to push the boundaries and create distinct models.”

Current car tech combines low innovation with high cost and poor usability. Worse, most tech is sold in ‘packages’ forcing the customer to buy low value, unwanted features to get what they want. BMW’s $2,1500 “Technology Package” does far fewer jobs far worse than our $650 phones.

Above all, we as consumers aren’t happy. There are clear jobs that cars are not doing and the automotive industry seems unable or unwilling to do. One study found customer retention averages a low 49% per manufacturer -- compare that to the Apple's 89% and fiercely loyal user base.  We are not happy with the slow innovations, we are not happy with the lack of real choices, and we are certainly not happy with the buying or ownership process. The buying process is so onerous, in fact, that three-quarters of people surveyed said they’d rather never set foot on a dealer’s lot.

Regulation concerns

My biggest concern is government regulation. Apple has strayed far from regulated markets seeking to build what they want how they want it. Last year, the Auto industry spent over $53 million to lobby the US government, while Apple spent just over $4 million. My concern is not over the spending differential (Apple could easily increase their lobby spend by 15 times and belly up to the Washington table with no problems). My concern is that that Apple’s core competencies does not include navigating highly regulated markets.  I will be very curious to see how Apple fares here.  

Can Apple Possibly Guarantee Our Safety?

Nope. They can’t. And they don’t have to. CGP Grey argue in Humans Need Not Apply that automated cars don’t need to be perfect -- they just need to be better than human drivers. It will be very interesting to manage the first major injury or death caused by an automated car but if they are safer on the whole, I hope cooler heads prevail (which goes right back to my concerns about Apple’s regulation experience).

It IS coming

Former GM CEO Dan Akerson warned “[Apple] better think carefully if they want to get into the hard-core manufacturing,” he said. “We take steel, raw steel, and turn it into car. They have no idea what they’re getting into if they get into that.” Somehow I doubt Apple, the company that holds 10% of all corporate cash held by all nonfinancial companies (and could buy GM three times over) would be entering into the market business-as-usual. If Apple has proven time again it will not design, manufacture, market or sell a car the same way it’s been done in the past. That includes pressing steel to make car frames.

In the end, the Apple car is coming. And by its code name, it is clear that Apple is aware and prepared for an epic battle. It won’t be easy, but if there is a company on earth that has skills, processes, and capital to disrupt the calcified juggernaut that is the auto industry, it is Apple.

Yesterday, Apple COO Jeff Williams described cars as "the ultimate mobile device". Buckle up, Dan Akerson, a Titan is coming.

Read More:

Neil Cybart discusses the Apple Car’s potential competitors, and the ripe-for-disruption state of the automotive market. He explains why Uber and Apple are both poised to rule the future of automobiles.

GM’s former CEO, Dan Akerson, explains why he thinks Apple expanding into the automotive market is a bad idea. “If I were an Apple shareholder, I wouldn’t be very happy.”  

Why the German automakers’ interest in Nokia Here is so important, and why it could spell trouble for Google.

MacRumors’s fantastic, chronological exploration of what we know about Project Titan and why we know it.

The somewhat dissenting voice, CNET explains why they think an Apple car is possible, but not anytime soon. They cite the supposedly tepid future of the iPhone as why Apple will explore the automotive space, but the logistic complications of doing so as why you won’t be driving an Apple Car next year.

[mobilesurge]

The 4 Forces Applied: Why Microsoft's Conversion Tool Won't Entice iOS Developers To Windows

Microsoft's newly announced conversion tool for bringing iOS code to Windows will not be compelling enough to move developers over. The 4 Forces help explain why.

The 4 Forces are a lens used to look at why people decide to change their behavior to use a new product or service. It is a wonderfully helpful way at looking at what factors drive us toward (positive forces) and away from (negative forces) a switch. For a more in-depth discussion, I highly recommend the excellent work of Bob Moesta and Chris Spiek at jobstobedone.org and especially recommend attending one of their Switch Workshops.

Here's a brief primer on the The 4 Forces:

Situational Push (positive)

This is the force that pushes us toward the new solution. What are the things driving us to want to change our behavior and switch?

Pull of the New Solution (positive)

This is the magnetic force pulling us toward the new solution. What are the new abilities we hope to acquire from the product/service? What will life be like afterward that makes us really want to make the switch?

Anxiety (negative)

What are the risks we see in switching? What do we fear getting wrong?

Habit (negative)

When we adopt a new product/service we are changing behavior. Habit is a strong force to overcome because it requires something to change. What are the parts of what we're doing now that make us want to stay with the current solution?

Let's apply this thinking to the Microsoft announcement and see how it illustrates the difficulties Microsoft faces:

Situational Push

Microsoft would hope to have something here with their 1.5 billion users split across (mostly) desktop PCs and Windows Mobile - with Xbox and even Hololens thrown in for a rounding error. All those people represent potential paying customers, so the marketing goes. Why wouldn't that be appealing to developers?

The truth is the push here is pretty minimal. First off, half of those users are on a PC owned by and locked down by a corporation. They might not even be able to install your app. Second, they are easily reachable by a web app which will almost certainly be a part of the plan anyway and which developers are likely to be far more confident in and comfortable with than a conversion tool that was just released. Charles Arthur did an excellent job raising most of these points in his piece about how this is a technical solution to a business problem.

Pull Of The New Solution

Here is where the forces in favor of Microsoft are at their weakest. What exactly is the amazing new world we will be a part of when we adopt this layer and develop for Windows? The only real selling points I can think of are: better IDE and using our existing code on a previously inaccessible platform.

As far as the IDE is concerned, give Microsoft credit. They are consistently mentioned with praise and admiration by most of the great developers I know who have even dabbled with .Net. And I can honestly say that "complaining about Xcode" is a pastime enjoyed by every great iOS developer - see TextFromXcode for fun and proof. But that doesn't mean that this will be felt as a strong pull. IDEs are the developer's workshop and it is no small deal to throw out all of your tools and start fresh. In addition, most of our complaints are nitpicks or related to other problems (e.g. code signing is awful, but that's mostly an Apple/IOS problem rather than entirely Xcode's fault). Now 3 or 4 years ago? Xcode was very unstable and there might have been enough concern to justify it. But give Apple credit, they've matured Xcode significantly since then. In addition, we'd still be working in Xcode for delivering iOS projects. This means that it can't be a full replacement, which also means I'd now have to operate often in two totally different workshops.

That leaves the languages problem - how much of a pull is it to use Obj-C on a new platform? The first awkward technical note is that Apple is actively pushing forward Swift, a language seen as an eventual replacement for Obj-C. So why start porting based on a language you probably will move off of anyway? But even setting aside that concern, languages are never a core problem in the decision matrix. I learned Obj-C because I wanted to be coding for iOS and it's pretty easy to see that I'm not alone in that fact. We engineers are tinkerers at heart: if there's a roadblock to something we want to do, we learn our way around it. Taking a short path might be nice if everything else was in place, but it's not that strong of a pull by itself.

Anxiety

Anxiety is where Microsoft begins to struggle mightily. There is a tremendous amount of anxiety in using any tool to port code meant for one platform to another platform. Engineers are well aware of the dreaded corner cases that always show up. Pesky, time consuming gaps in the promise of easy reuse and the reality of necessary polish. Even if Microsoft's technical execution is stellar (and I assume it will be), there will always be fundamental concerns around how things want to be used on a specific platform that will make things messy.

But a far bigger concern for developers is maintenance. Maintenance is a strong pit of anxiety, combining the least fun parts of a project with the least rewards (no one pays for bug fixes), and the most risky and time consuming efforts. Adding the complexity of a conversion framework on top of that for a platform you (likely) don't personally use means you've got a lot of anxiety to deal with. There had better be a really strong reason to jump into this thing, because it's a giant engineering red flag.

Habit

The last force is obviously the specific issue that Microsoft is hoping to overcome - habit. Developers are not currently developing dedicated Windows-platform (Phone or otherwise) apps but rather staying with the dominant iOS, Android, and Web. Habit is a powerful force and it's hard to see major changes that will act to disrupt it in this case.

Even in areas where habit might be a strong pro-Windows force, such as large corporate environments, this is working backwards. Most likely these are .Net developers currently building out for Web. In that case, the tool with habit on its side is actually Xamarin, not Microsoft's new tool. I've long thought it made sense for Microsoft to really hit this hard with an acquisition of Xamarin. It would give them a strong case for enterprise: build your cloud/API, web and client code all from the same stuff using the same tools that you're already familiar with. That combination might be incredibly compelling for a .Net-dedicated enterprise to adopt based on force of habit alone, but so far there hasn't been much movement on that front.

Note: Microsoft also released a compatibility layer for Android as part of a similar effort. This piece is focused on iOS since the tools are different in approach - iOS is a conversion tool, while Android is a compatibility layer on top of Windows.While some of the motivations and specifics are different, I also believe it is doomed by much of the same analysis.

[mobilesurge]

Why Focus Groups Lead to Horrible Software

The first rule of great product development is: Don’t ask the customer what they want. But why?

Well, customers have no idea what they want. More importantly, they can’t tell you why they really buy your product. I love the Henry Ford’s quote, “If I’d of asked people what they wanted, they would have said a faster horse.” Funny, right? But also so true.

Seems logical to think “Who better to ask then the customer as to why they buy a product and what they’d love to see as improvements?” And of course, to get any sense of how to improve our product, it seems logical to bring in a large group of people (focus group) to ask. Once the customer tells us what they really want we can make it and undercut the competition with our amazing product. But there are heaps of reasons why this will lead you to developing terrible products.

First, customers aren’t experts in your field. They have no idea what innovations are coming that can deliver a radically new solution for their problems. They only know what’s currently on the market. So when asked, at best they will demand for better, faster, cheaper…. based on what they know, they want a faster horse. But is that really what they want?

What focus group would have told Henry Ford that he needed to take emerging innovations in manufacturing, combustion engineering and design to create a petroleum based vehicle?

In 2006, when the Motorola Razr was selling a staggering 50 Million units annually, which focus group would have suggested a heavier, larger phone with 1/7th the battery life and no keyboard that doesn’t flip to close (which was such a fun and practical feature)? But that’s exactly what we got with the first iPhone. Seven years later the iPhone is still heavier, larger, with a one-day battery life, and no keyboard or flip. Despite everything we clearly stated we wanted, the iPhone is one of the most profitable and successful consumer devices in history. And Motorola? Well Google bought them just for their patents.

Second, users don’t know why they buy your products. But how can they not know? When we make a purchase, our reasons aren’t conscious or even rational. We can recite all the reasons we think we buy, and those reasons make up an entirely plausible narrative. But we’re just guessing. We can say we bought Product X because it tastes best, or hast the best value, is convenient or (least accurate of all) just because it was a spontaneous decision.

The cardinal rule of product development is that there are no spontaneous purchases. As soon as you resign your product to the mindless spontaneous purchase category, you’ve copped out and done a real disservice to your product and the consumer.

But the real reasons behind why we buy what do are far more complex, subtle and emotional than we even realize. Bob Moesta hammers this point home in a fantastic Critical Path podcast. But in essence, the story we tell ourselves and story that actually forms our purchasing decision are not even remotely related to each other. As opposed to focus groups, individual customer interviews are valuable (don’t miss our next post on how to interview your customers in a Jobs To Be Done context), and help us tease out the real jobs customers are hiring our products to do.

Finally, customer choices are (almost) never about price. They are about value. Sure there are some items that a customer simply cannot buy because they are impossible (a middleschool teacher probably doesn’t have the money to buy a $58M Gulfstream G6 ). So maybe a slightly longer version of this rule should be: “If the customer is able to buy a product, price is never a factor.”

When someone tells you your product was just too expensive what they are really saying is it was not valuable enough for them to give up other purchases. We buy items we value. If the value is high enough we forego other purchases in place of the highest value product.

Ask any of us and if humans are rational and most of us will answer with a resounding “Absolutely not.” We are irrational and nuanced in almost every aspect of life. As product developers we need to do the work and dive deep in the subtle and subconscious reasons that really drive customers to hire products. Gleaning the real motivations and desires behind a purchase is a hard task, but essential if you are to create a product with real and lasting value.  Relying on a focus group for your answers is easier but will have you breeding faster horses while your competition makes cars.  

[mobilesurge]

Why IoT is a Really (Really) Big Deal for Us and for Samsung

If you are like most people not living under a rock, you’ve heard a lot about the Internet of Things, and even if you have no idea what it is, you’re already tired of the buzzwords. Today I’ll explain why it’s such a big deal for all of us, and why out of all companies Samsung is champing at the bit hardest over it.

Beyond wearables (with the most attention going to the the Apple Watch) it’s all people seem able to talk about. Hell, Samsung is jumping into IoT with both feet in hopes of pulling out of their tailspin decline in profits. So why should you care? Why is your toothbrush having an IP address a big deal and how on earth will that improve anything in your life? (Arms crossed. Foot tapping.)

Excellent question. First of all IoT it not for everything. As sci-fi and interesting as it may seem, I don’t see a use case for a IoT toaster but, hey, you never know. The whole idea (and the resulting excitement) around IoT is that ordinary products will now be connected not only to the Internet, but to other IoT devices, wearables and, of course, smartphones. It is precisely this interconnectivity that will improve upon and find new jobs for devices that have previously become just good enough.

Let’s take that toothbrush I mentioned. The invention of the SoniCare seems like the last leap forward with this tool. And one may ask, “what possible benefit could a connected toothbrush provide me?” After all, it's just brushing my teeth. I have my SoniCare. I brush for the full (not really) 2 minutes. Done. That’s the job I am hiring my toothbrush to do: To brush my teeth for the requisite 2 minutes. “How will connectivity help?”

Just ask any of us when we are getting our twice annual dental cleaning. There are so many more jobs we really need our toothbrush to do that it's not doing because it can’t on its own. But a connected toothbrush could be far better at communicating not only how long I have left to brush but how to improve my brushing. Even if I’m brushing for the requisite 2 minutes (which I don’t) I know I’m not cleaning every tooth correctly or even spending remotely the same time on each tooth. How do I know? My dentist tells me every six months in painful detail all the ways I’m failing. But that’s one abstract conversation twice a year for 5 minutes. For me, that’s no where near enough support to help me break years of bad habits. And those bad habits lead to real issues that lead to longer cleanings, cavities, gum recession, etc.  

Let’s imagine an IoT SoniCare. Pushing too hard? I get a taptic nudge on my Apple Watch and push notify to my iPhone. With a few sensors I know if I’m bushing equally or skipping quickly over sections. Oh man, has it been 3 months already? Alright, I’ll accept the suggestion to add replacement heads to my Amazon cart? And of course there’s gamification with leaderboards, achievements and customized tips. Yep, all this and a lot more from a toothbrush.

This is precisely why Samsung is so excited by IoT. Samsung manufactures a lot of different products, many of which will likely get connected in the coming years. Unlike Apple whose product can all fit on a kitchen table, Samsung is uniquely equipped to adapt their large and existing ecosystem of products into a massive IoT line. 

Further, much of their experience with Android could be applied to IoT since open source Android (not iOS) will be the operating system of choice for IoT manufacturers. This is especially exciting for Samsung which is simultaneously losing their most profitable high and low end smartphone market share to Apple and Xiaomi. As IoT opens the door to new and improved jobs to be done for countless products it is Samsung that is poised to rule IoT.

[mobilesurge]

What a Successful Slack Implementation Looks Like

Tips to make Slack an amazing tool for your team.

At BiTE, we're huge fans of Slack. For the uninitiated, Slack is an amazing collaboration tool. It starts with chat; both person-to-person as well as group chats (“channels” in Slack parlance) are exceptional. It handles sharing files between team members, offers integrations to other services, and has full text and file search of all your past communications.

With all the advantages it brings, Slack has been thought to be the fastest growing piece of enterprise software ever. But we've heard a lot of people ask how they can get the real power out of Slack. Here's our tips for a successful Slack implementation:

Choose channels wisely

Channels are the heart of Slack, and where your team will do the bulk of its collaboration. You'll want channels that have a focused purpose so that people will clearly understand why they want to join. Don't be too stressed out when you first start as this is something you can easily adjust as you see how your team is operating. Definitely a channel for each team or project is appropriate.

Take some care to have discussions on the correct channel. This allows people who are not directly interested to be left out. It also allows people to dip in or out of channels without missing something important. If you find that a specific channel is supporting too many threads, you might consider breaking that channel into another one.

Zero internal emails

This is more of a noticeable side effect of a solid Slack implementation rather than a mandate, but it's a huge indicator of success. As your team is using Slack more and more, you'll start noticing that you drop out to email a lot less. Slack's conversations are so much easier to see than normal email threading that they are often far easier to read. As the conversation occurs in real time, it's much easier to take into account different voices since there's less chance of them crossing over each other in route. And it's much easier to involve everyone relevant by simply using the correct channel since there's no need to remember everyone who needs to be notified.

Slack is a big upgrade from email when new people join a team as well. Before Slack, when a new person joins they have an empty inbox and no context to any previous conversations. But when they join Slack, they can actually go back and look at past discussions, see some context around why decisions were made, and get a feel for how the team likes to operate.

Load up on integrations

Integrations are where Slack starts to become really powerful. Integrations allow you to hook other third party tools into Slack so that they can post messages to a channel or respond to messages within Slack. For instance, we use Pivotal Tracker to manage our projects. When someone on the team updates a task (when they start work, leave a comment, etc) it immediately posts a message in Slack noting the change and providing a direct link to the task. Now everyone on the team is aware something has changed and it happens right in the same thread where we'd discuss the changes anyway - far more useful information than simple email notifications.

To get the most value, you'll want to integrate every tool your team uses with Slack (if possible). Bug trackers, project management software, version control, Google Hangouts, screen sharing - if there's an integration available use it. We've gotten to the point where we look for Slack integrations as a starting point in evaluating a tool. The reason is simple: the more things tie back to the central hub of Slack, the more effortless communication becomes and less likely you are to miss things.

Complete confidence in search

One of the superpowers you'll gain in a successful Slack implementation is the ability to find nearly anything. When you're having all your conversations in Slack, anything that you've previously discussed or shared is searchable. This means when you want to go back and grab that sales number someone told you or that really apropos link, it's a simple search away.

I'm a chronic filer and I know that search has often made promises like this. If you're like me, you'll hear this promise and immediately discount it. But take it from me, it really does deliver on the promise. Confidence in search is a great indicator of how well a Slack implementation is working.

Hopefully these tips help your team become powerful Slackers. Leave a comment with any tips of your own.

[mobilesurge]

BDD Toolbox: Happy Path/Sad Path

BDD Toolbox is an ongoing set of posts to give you tools to aid in the process of doing Behavior Driven Development well. Today we’ll take a look at Happy Path/Sad Path - a tool to ensure you’ve captured success and failure cases for all of your scenarios.

Happy Path/Sad Path is a way of looking for meaningful examples in the course of crafting our specifications. It works on the idea that for every success case there is often a failure case as well. Before we dive further into Happy Path / Sad Path, let’s revisit one of the key practices of BDD so that we understand why this is an important tool to master.

Not Tested = Not Built

BDD is an automated acceptance testing framework, but it is also a set of disciplines that were learned from the best practices of Test Driven Development. One of the great disciplines of working within BDD is that you only build what you need to make a failing test pass. This is important for a number of reasons. By always starting with a failing test, we know that any code we add will have a corresponding test that ensures it stays correct. When we run the test suite later, it will tell us that everything is behaving as we previously decided was correct. Additionally, working with a failing test means that we’re focused only on building things of real business value. It’s easy to fall into traps where you think something orthogonal is vital1. Because BDD is based around acceptance testing, we want to know that if all our tests passed, the system truly is in an acceptable state.

This makes it essential to capture all relevant scenarios in our feature files. While everyone on the team should feel empowered to stop the process at any time and ask if something seems missing, the best place to capture scenarios is at the 3 Amigos meeting, because all stakeholders are present. This is where Happy Path/Sad Path becomes a very useful tool.

Two Sides of The Coin

When you’re looking at a specific story or feature, you’ll nearly always have one set of rules if it goes right, and a set of strategies for dealing with something that goes wrong. For instance, you have a login form. The user can give you a valid username and password - Happy Path. Or they can mistype their password - Sad Path. By knowing that these two sides exist to nearly every requirement, you can be actively looking for them when capturing scenarios. Ask yourself when putting together a scenario if there’s an error case (or cases) that should also be handled. There will often be multiple ways for something to go wrong, so don’t make the mistake of thinking you are only looking for a single failure. The key to success is getting in the mindset of asking “can you give me some examples of where this can go wrong?” whenever you see a Happy Path in your specifications.

Smoothing the Path

One of the great advantages to Happy Path/Sad Path is that it helps you catch edge cases up front. A huge benefit of doing BDD well is being able to know your edge cases before you start building. Every seasoned engineer can cite a project that was humming along smoothly when all of a sudden they discovered a requirement that broke some base assumptions they had built into the product. Usually the only way out is a huge refactor that no one accounted for in the timeline. The better you can get at avoiding those late-discovered edge cases, the more smoothly and predictably development will run.

Incidentally, I first learned Happy Path/Sad Path from Aslak Hellesøy, the creator of Cucumber. During a class I took with him, he caught me writing code that didn’t make a failing test pass and hammered this discipline home. So I understand the engineer impulse to build it “because we know we’ll need it,” but in the end it’s much wiser to stop and ask your team if this should be added to your tests than to simply go and build it. ↩

[mobilesurge]

The Path Less Traveled for Talent Recruitment and Retention

According to London Business School’s Annual Global Leadership Summit poll, over a third of surveyed companies project more than 50% of their workforce will work remote by 2020. That may seem like a surprising number until you realize how much a remote workforce could benefit your company. Here’s how it benefited ours:

When Brant DeBow and I formed BiTE we had several goals for recruitment and retention. We wanted to hire only senior resources. We never wanted to offshore any of our work. And we wanted the chance to invest in long-term relationships with our team, which meant we also wanted ultra low turnover.

These were lofty goals for any company, but for a self-funded start-up we knew they were enormous. Finding talent is always a struggle, and we watched the talent arms race between large tech centers wage on. Companies both gigantic and small (in large tech center cities) competing aggressively to poach the best resource from competitors and keep their own resources from being nabbed in the process.

Spend any time in Silicon Valley and you’ll see this fantastic world where programmers are wooed by lavish parties that tout how amazing it is to work for [insert huge company/well-funded start-up here] reminiscent of the unabashed dot.com days that would make F. Scott Fitzgerald gasp. But to what end?

It’s a race that drives salaries to the firmament and all but ensures high turnover. If we had limited ourselves to this small and hotly contested tech center talent pool, we wouldn’t have been able to satisfy our goals.

So how could we attract and retain senior talent in this atmosphere? We decided to hire the best talent -- no matter where they lived. Though it went against the norm, we built a company without the office, expanding our recruitment from 20 miles from a central office to the entire United States. And we made remote work the rule not the exception.

But how is a completely distributed model different from tech companies that allow some remote work? Companies that allow some remote work run under an entirely different assumption: while working remotely keeps resources happy, the “real” work gets done at the office. And when remote work is not at the core of your process, remote workers are often left out of the loop. This disconnect between onsite and remote workers further reinforces the concept about where the “real” work gets done.

When everyone is remote, everything changes. Chance meetings occur over Google Hangouts or through our favorite tool, Slack. No one is left out because everyone is using the same tools to collaborate. What once seemed like a liability is a huge bonus as workers are happier, far more productive and actually communicate much more easily. Why? When everyone is connected by a host cloud-based remote tools (like Slack, Pivotal Tracker, Google Docs, Dropbox, Google Hangouts, etc)  both on mobile and their laptops you create the new virtual office with a strong culture staffed with the best talent from all over the country.

The new virtual office is by far a more adaptive, flexible and more productive that, thanks to a host of newly emerging tools has finally delivered on the promise of a virtual workforce.

[mobilesurge]

From Waterfall to Agile

When we began BiTE, we were a fixed price/scope studio. And while we were small, this model worked. Mobile was in its infancy, so projects were relatively straightforward. During these early days, we could grind out change on nights and weekends even if it wasn’t ‘in-scope.”

Fixed Scope Pitfalls

But as mobile started to grow in scope, complexity and budget, things changed. Fixed price projects were losing money, endless long hours and weekends were burning out our people and (worst of all) change orders and date slippages were infuriating to our clients. Often, clients simply could not get more budget to approve a change order. Schedule slippages were unacceptable, since they threatened hard deadlines. And scope, as we said, was fixed with the assumption that everything would go as planned. But of course, we all know the only guarantee in any project is change.

Exploring Agile

We needed find a way to run BiTE and still meet our clients’ most important objectives: quality software on budget and on time. So we moving to an Agile model. We fixed time and resources and kept scope dynamic. With fluid scope we eliminated change orders. Since resources and duration were fixed, we met clients’ budgets to the penny without threat of overages. All this while never, ever missing a release date. Because the highest priority items were always built first, the client got their “must-have” features. And if time and budget were insufficient to get every feature into one round, the lower priority items moved to a future release.

The Results

Agile made us fast. Agile made us adaptable. And Agile provided our clients with assurance that release dates would be hit each time and costs were certain. It aligned our internal goals with those of our clients and most of all, Agile helped us build better mobile apps. As mobile and the needs of our clients change, we continue to grow and refine our Agile implementation.

[mobilesurge]

From Manual Testing to BDD in Mobile App Development

Over our seven year history, we have evolved our software development and QA processes significantly. We started app development knowing mobile was the future, but back then our QA process was decidedly retro. We manually tested our software on each device, plodding through the same test scripts over and over in iOS on a host of Android devices. Aside from being incredibly tedious, this manual process increased the price of our services and, most importantly, slowed development.

Manual Woes

As Android moved from a marginal to major player, fragmentation slowed QA speed further. With our move from waterfall to Agile, manual testing showed two more major flaws:

1: Software needed to be iteratively tested on both platforms and all devices throughout the course of the sprint. QA wasn’t able to keep pace, which limited their ability to test for the more insidious bugs excellent QA leads are great at rooting out.

2: QA needed to interpret and translate user stories into test scripts. But since QA was completely downstream and not part of the story development process, they were forced to translate each story into proper test scripts. This created huge translation risks. Plus, QA had to constantly monitor the storyboard and adapt as changes occurred. This led to wasted cycles testing outdated stories and a feedback delay from not testing changes immediately.

Enter BDD

With BDD, QA went from a downstream interpreter to an upstream contributor. Automated BDD scenarios freed QA to focus on edge case bugs that can become huge issues in live production environments. But BDD’s automated testing is not the only thing BDD allowed us to do well. BDD creates a common, plain English-based language to communicate features seamlessly with all members of the team -- from Product Owners, senior leadership and Tech Dev, to Creative and QA.

Like most beginnings this wasn’t without its problems. Our scenarios, like those of many BDD novices, were imperative (highly detailed, long, complex and overly specific). Since they were overly detailed clients and internal resources saw BDD as tedious, complex and prone to error.

BDD Evolved

Once we made the shift from imperative to declarative we were able to write fast, simple and clear non-technical scenarios that told our team exact what to build instead of exactly how to build it. With this shift we were able to take full advantage of BDD to unify communication, automate testing and streamline Agile development.

[mobilesurge]

BDD Toolbox: Outcome Questioning

BDD Toolbox is an ongoing series of posts in which I'll give you tools to do Behavior Driven Development well. Today we'll take a look at Outcome Questioning - a tool to help ensure all relevant details are captured in your scenarios.

I've talked in the past about Behavior Driven Development and how I believe it directly addresses the fundamental problem of software. In fact, Joseph and I gave a talk on that very topic at The App Summit. BDD seeks to increase collaboration and understanding by bringing key resources together for a 3 Amigos meeting. In a 3 Amigos meeting, you work through real world examples of the business rules you're trying to achieve in your software. One of the key goals is to make sure we've captured all of the necessary details that will drive the software we're building.

Outcome Questioning is a great help to make sure that our scenarios don't inadvertently miss any key details. I first learned about Outcome Questioning from Liz Keogh in her book on BDD. The basic idea is simply a question we can ask ourselves: Are there any other outcomes that also matter?

Given-When-Then

BDD scenarios are structured in a Given-When-Then syntax:

Given: Sets up a context; puts our system in an initial state When: Performs an action on our system Then: Tests the system to ensure the correct outcomes occurred

Most often, the Then clause will be where our tests fail because this is the behavior we're trying to build into our system. As such, it's critical that we know our tests represent everything relevant to the business. Remember, BDD scenarios are our acceptance criteria for our application. We must know everything that is needed to make it acceptable, or we will forget to build necessary pieces.

An example

In true BDD fashion, let's look at an example. Let's say we have a story about our ATM software: "Withdraw cash". We take that story into our 3 Amigos meeting and we've expanded it into the following BDD scenario:

Given Ralph has an account balance of $250 When he withdraws $20 in cash from the ATM Then he should receive $20 in cash

This looks like it captures our scenario pretty well. All of us are familiar with withdrawing cash from an ATM and this is spot on. Now, let's ask Are there any other outcomes that also matter?

If you're playing along, I hope you spotted the biggest hole in our system: we haven't debited the money from Ralph's account. If we had not been careful in our 3 Amigos meeting, we might have missed this detail and run our bank directly out of business. Let's update our scenario and make sure that doesn't happen:

Given Ralph has an account balance of $250 When he withdraws $20 in cash from the ATM Then he should receive $20 in cash And his account balance should be $230

Now that we’ve captured that key fact, our developers will know we must build it into our system. In addition, we now have a test case that will alert us if it’s not included. We’ve managed to avoid a banking disaster.

Another Tool in the Toolbox

As we've seen, Outcome Questioning can be an important tool in your BDD toolbox. It's a great thing to keep in mind as you write your scenarios with your team; another lens by which to analyze your business and it's examples.

[mobilesurge]

What are the Different Options for Location Aware Mobile Apps?

Many product owners realize that location can play a huge role in an iOS or Android app. But there are many options and permissions to consider when building in location-awareness.

Location has a long history with the smartphone; it was even a key feature in the launch of the original iPhone. When the iPhone 3G moved from cell-tower triangulation to full-blown dedicated GPS, location took a permanent place in the fabric of mobile apps. However, like all things in mobile, the breakneck pace of innovation has caused an explosion of potential options and it can be somewhat confusing to understand the subtle differences.

Here's a rundown of the different ways that mobile apps can access and use location:

Geolocation

Geolocation allows you to determine the rough location of the device. If you've ever used one of the countless store locators, or searched for a restaurant nearby in Yelp, you're probably familiar with geolocation.

Geolocation works via Assisted GPS, which uses some pieces of data to quickly obtain an accurate position of where you are based on a network of satellites orbiting the earth. The result is that you can determine a lattitude/longitude point on the map where the given device is located. The accuracy of that point will generally improve as the device has more time locating satellites and processing data. This is why you'll see the phone show you as a big circle on the map, which then shrinks down into a small point as it gets more confidence in your location.

Geolocation is the most mature of the different mobile location technologies. As such, it has universal support across Android and iOS and comes with very few caveats. You'll want to target geolocation when you are getting a broad location of a user (i.e. determining where the nearest Starbucks is or if they are currently in a brand's store). The key is that the location is broadly accurate, but not fine-grained - e.g. you can tell which Walmart they are in, but not which aisle.

Permissions:

iOS: you'll need to ask the user before you can access their location. Normally this is the "when in use" location permission, as your app will not be accessing their location when you're in the background.

Android: as part of your app's listing in Play, you'll need to require coarse grained location at least. However, when using Google Maps, Google also suggests fine grained location and a few others for things like downloading/caching tiles.

Geofencing

Geofencing expands on geolocation technologies to create a virtual "fence" around a specific location. This allows for notifications, actions, or UI change to occur. As an example, let's take a look at how Starbucks uses Passbook to show you your loyalty card when you're at one of your favorite locations:

First, inside the app you sign in and enter your loyalty card details. You then choose specific location(s) you frequently visit and it stores those along with your loyalty card in Passbook. Each of those locations is marked by a specific circle around a geopoint - this is the "fence". Think of it as an invisible circle, with it's center in the middle of the store and covering the area around the actual store. When you drive up to the window and hit any button on your phone, your location is compared with all of these fences. It then determines you are, in fact, at a specific location, so it shows you and easy lock screen alert you can swipe to bring up your card to pay.

Geofencing is great for any task or activity that is specific to a geographic context. For instance, OmniFocus - my task-management app of choice - allows you to make a list for a specific location. So if I store a few things that I need at Lowe's, the next time I'm there, it'll pop up and remind me of the list of things I needed to get there. Because your app knows the user is in a specific geographic context, these sorts of interactions can be very powerful if used precisely. Short circuit the longer process of remembering your app, launching it, and drilling down to the context by taking users directly from the alert to the context.

Permissions:

iOS: As the fence will be active and alert your app, you'll now need the more ominous sounding permission that tells users you can track them all the time, even when in the background.

Android: The fine grained location required for geolocation is also required here, but you'll need the additional permission of location hardware.

BTLE / iBeacons

iBeacons are small devices that transmit a specific signature over Bluetooth Low Energy (BTLE). By placing them in specific locations and examining the signal strength, they can provide a much more precise location of the user's device. Compare this to our geolocation example: the app knows not only which Walmart you're in, but could know which aisle or give you specific directions in the store to get to the item you were looking for. As such, they are particularly useful in the context of retail.

But they are useful in non-retail apps as ways of providing location-aware context. One novel use by MLB offered up a video about the Mets' iconic statue when fans were close by it in Citi field. Location-aware content, much like geofencing, can be a great way of reducing friction in your interface. Rather than look through a long list of different things in a store, museum, or ballpark, the app can serve up the precise content that is relevant to where the user is currently standing. When you make the interface fall away into the background, you give the users a more personal interaction that feels almost like magic. As Golden Krishna has been proclaiming, "The best interface is no interface" - or in this case, far less interface.

The big caveat - on Android - is that BTLE is not uniformly supported across the many devices and manufacturers. A lot of the flagship handsets from most major brands will support it, but you'll need to be careful to degrade gracefully if it's not supported.

Permissions:

The permissions on Android and iOS are both the same as geofencing.

[mobilesurge]

What Shoveling Snow Taught Me About Making Great Mobile Apps

How shoveling snow this winter helped me contemplate what makes great software

I live at the top of a steep and twisting driveway that quickly turns into what I’ve described to my team in Slack as “a snowy deathcoaster”. While spending a few hours trying to end my family’s snow-exile, my mind drifted to thoughts of how to build great software.

Here’s what software has in common with shoveling snow:

A delicate balance

It’s utterly impractical to try to remove all snow off of my driveway with a shovel. I saw a neighbor using a tractor and even that didn’t go very fast. On the other hand, it’s certainly going to be too dangerous to simply drive up or down it without any snow removed. Like Aristotle’s Nichomachean Ethics, the right path lies in between errors of excess or deficiency.

Software is always about finding the delicate balance between never shipping, and shipping half-baked, unstable code. Often great teams will have a little bit of each personality - what Rands calls “Stables and Volatiles" - and hold them in a friendly tension.

As always, focusing on the customer and treating the product as central aids this balance. By knowing the customers need new features and our product is not yet good enough, we are motivated to constantly push out new releases. At the same time, customers need a stable product and we can’t push out things that negatively impact them.

Tools are essential

Joseph and I have a slide in our talk about software that simply has the equation: Outcome = (Time + Effort) X Tools

It’s a simple but extremely powerful concept. The right tools are multipliers that can vastly increase your ability to make things faster, better, and in a repeatable fashion. I’ve never been more thankful for a physical tool than when I was out shoveling snow. How I rejoiced that I didn’t buy a cheaper model!

Likewise, when it comes to software, you can’t skimp on tools. Make sure your teams have the best tools to work with and actively search out things that can make you better. If there’s a 3rd party service that can help you go faster, don’t hesitate to pay for it. If your team can spend some time automating a difficult process, you’ll immediately feel the benefit. In the long run, cost-cutting turns into wasted money when you realize how much productivity you sacrifice. But more importantly, choosing the right tools makes the people who work on software more motivated to do great things since they waste less time worrying about the more tedious things.

Ignore fun

When I was shoveling snow the bottom of my driveway was mostly clear and you could chip off these huge patches of ice with a satisfying toss of a ton of snow. It was hard to tear myself away from this fun task to work on other parts that were going to be more of a battle, but needed to be cleared.

In software, there’s always some tempting, fun aspect of a project. It’s a black hole of time, but you still feel so productive while you refactor it to ever cleaner states while ignoring the way more difficult and necessary parts of the product. It’s essential to exercise some discipline and make sure that the next task you pick up is actually the next most vital feature. It’s often a good idea to jump into a project or sprint with the idea of tackling the least “fun” aspect of it - after that’s down, everything else feels like it’s moving quicker and you don’t get lost in features that don’t really matter.

Iteration is power

It’s pretty daunting to stare down a driveway that’s iced over and full of snow. The only way to get started is to make a small patch of it less awful than it is now. But by working diligently, it slowly starts to fade away and clear up. This is the power of iteration: small incremental changes that have a huge cumulative impact.

Obviously, this is directly applicable to software. Iteration is the key to quickly and consistently delivering quality software. By keeping an eye on the big picture but focusing in on the next steps, things slowly start to take shape and approach the product you’re after. There’s few things more satisfying than when your team starts to see all these little efforts add together and make something exciting to share with the world.

[mobilesurge]

How to Do BDD and Agile Well for Your Mobile App Project

In a previous post I wrote about how Jobs to be Done theory can be used to develop a clear and powerful mobile strategy. But once you have this mobile strategy in place, and have developed your stories, how do you then execute BDD well in an Agile environment?

Going from a waterfall, fixed-price agency to where we are now with Agile has taken seven years. But over those years we’ve grown and adapted our processes to eliminate pain, decrease complexity and increase efficiency for ourselves and our clients. 

It’s important to remember that no process is set in stone. Any process is a living, breathing thing that grows, evolves and can even die when it’s outlived its usefulness.

But here’s the current overview of how we effectively integrate BDD and Agile into our client-services business model.

Planning

1. Prioritize

Once you have your initial stories written they should be prioritized. There are a lot of great tools including lightweight ones like Trello, or heavy duty ones like LiquidPlanner. We currently use Pivotal Tracker. We’ve loved and abandoned (chabudai gaeshi) five project management tools in our seven years of operation. Cards on the wall is a classic option, but not one we’ve embraced because even if the mobile app team is colocated the client invariably is not. Cards on the wall can’t help the client which in turn makes them feel disconnected them from the rapid agile flow and creates a lot of unnecessary communication problems. 

But regardless of the Agile tool we are using, once we have the stories listed by priority we determine the minimum viable product (MVP).  

2. Estimate

Depending on the project size and the number of stories, you may want to estimate just up to the MVP. If stakeholders need a higher level estimate for all known stories, everyone on the team should see this as an order of magnitude estimate, with the clear understanding that many changes in the product will occur in the future.  

As new MVP stories are added, you’ll want to ensure these are estimated quickly, keeping everyone on the team aware of the total number of sprints needed to release your MVP. If you need more sprints but there isn’t enough time or enough budget, you may have to move the lowest priority MVP features to a future release.

Execution

3. Back Log Audit

This is a simple but key step where the backlog is reviewed by the team to ensure that it’s current and properly prioritized.

4. Load the Sprint

For mobile we prefer to work in three-week sprints. This allows us enough time to build wireframes, comps and establish the Technical Architectural plan, develop the needed features, showcase the release candidate and get stakeholder feedback, revise, bug fix and release at the end of the sprint.

5. Three Amigos Stories to Scenarios

As a BDD shop, the three Amigos (The Product Owner, Developer and QA) unpack each story and identify the specific scenarios (including the happy path/sad path) needed to satisfy each story in the sprint. In addition to providing the team a clear vision of success, the scenarios become automated test scripts which are run throughout the duration of the sprint.

6. Wireframing, Comping and Technical Architecture

While development is starting, the important ground work should be laid. The User Experience team meets with Development and the Product Owner to determine how the interface should be restructured to accommodate the new features. They then incorporate this knowledge into the existing wireframes and adjust comps accordingly.

Meanwhile, the Development team and the Technical Architect research what will be required to implement the new features and strategize on how to incorporate the new code into the existing product.

7. Development

Development has full BDD scenarios to start coding/testing against - even before they integrate the UI. This allows for "headless" testing of model objects, API, etc. And since tech dev was in the three amigos meeting there is significantly less risk of programmer churn while wires, comps and technical architecture strategies are being developed or throughout the sprint lifecycle. BDD enables maximum coding velocity throughout the entire sprint.

8. Release Candidate Demo/Testing and Bug Fixes

At this stage, the sprint’s release candidate is demoed for all stakeholders. Stakeholders are walked through each feature slotted for release in the current sprint. Small changes are implemented in app immediately, while larger changes are added to the backlog for prioritization. Finally, stakeholders determine if they would like to release the app onto the app stores or hold the release, adding another sprint of features.

9. Release

Whether it’s the first or the 15th sprint, we prepare the mobile app for release onto the app store. Features are completed within a sprint and do not span multiple sprints. By finishing features within a sprint we can keep the project flexible as priorities and features invariably change.

[mobilesurge]

Why Uber, Snapchat and Tinder are So Successful Despite Themselves

Mobile Apps have created a new generation of tech moguls. As with everything in mobile, app innovations move at lightning speeds, and so does the creation of billionaire entrepreneurs. Take 23-year old CEO and co-founder of Snapchat Evan Spiegel. Snapchat has a current valuation of $10 billion. Just to get a little perspective, Spiegel was only 16 when the iPhone first launched.

As this newest round of mobile billionaires take their start-ups to dizzying heights, they also seem to be redefining the depths of entitlement, misogyny and poor choices, epitomizing the very worst of the frat boy persona.

Let's review:

Snapchat suffered a very public embarrassment when Spiegel’s old emails were leaked to the public. Far beyond normal college nonsense, these emails were grossly misogynistic, offensive, and disturbing. But it didn’t seem to slow them down. While this may be infuriating to our collective senses of decency, let’s think about why this PR disaster had no effect on them: Snapchat does a real job for users and it does it very well. It allows users to share fleeting, ephemeral moments of their lives through images.

It’s the distillation of the best and most popular parts of every other social sharing app, giving users just what they want and nothing extra. This laser focus on one job is responsible for the app’s meteoric rise from a germ of an idea in 2011 to a $10 billion valuation.

Why wasn’t Snapchat gored for Spiegel’s behavior? Because the job users hire it to do is not related to users’ image. If Tim Cook would send similar emails (I know its beyond imagination but try) Apple users would revolt. Why? Because we hire Apple products to help tell others who we are as people. We don’t do that with Snapchat. So Spiegel’s character, while embarrassing and offensive, hasn’t deterred investors or users.

Tinder’s missteps were even more widespread and far more public. In a much-publicized lawsuit, Whitney Wolf alleged that both founders Sean Rad and Justin Mateen were guilty of “atrocious” misogyny.

The proof was in dozens of hateful texts and emails, all of which culminated in Mateen being asked to step down. Yet use of Tinder hasn’t slowed, with more than 10 million matches being made every day. They’ve even launched a paid arm of the company, and their current valuation is $1 billion. Again, because Tinder understood that the very first and critical thing we want to know is: are we physically attracted to this person and do they like me back? Understanding this, there are no profiles just pics and age. Like or Don’t Like. Elegant and powerful. Again, their laser focus on a clear job to be done is what has made them weather a scandal storm that should have toppled them.

Uber is maybe the most egregious example of all, not because it’s founders have been caught sending compromising emails (they haven’t), but because they lied to users about their driver screening policy (that is, they pretended to have one). To date Uber drivers have been implicated in a number of sexual assaults and even one case of vehicular manslaughter. Nonetheless, Uber is now valuated at a staggering $41 billion, and is active in 230 cities. I use Uber a lot, because it solves my problems (getting me quickly from A-B, no tipping, secure payment) better and more efficiently than any cabs ever could.

If it seems like we’re being apologists for inexcusable behavior, we’re not. Bad behavior is unacceptable especially those we have entrusted with our privacy moments, our hearts and our safety.  But the the bottom line is that if we hire your brand to do a utility rather than tell others who we are it doesn’t matter what sort of repellent behavior they exhibit, as long as they solve our real problem.

[mobilesurge]

Net Neutrality: A Primer

This Thursday, February 26, Net Neutrality comes up for a vote (that is, if the Republicans don’t get their wish for a delay), and it looks likely to go through. Obama has expressed his support, and the tide of public opinion is on the side of Neutrality. If you’re like a lot of people, you know only that Net Neutrality is something important you’re supposed to care about, but the details are a little fuzzy. Don’t fret. Here’s a brief history of Net Neutrality, and everything you need to know to understand Thursday’s vote.

The back story

Since 1999 the FCC and Congress have sought to balance consumers’ and content creators’ access to the internet with protecting the investments of the companies who build the data networks. In 1999 the issue was about access to old telephone networks for dial-up service, and the question was whether or not to treat the internet service providers as a utility, subject to Federal restrictions and rules. For over a decade the answer was no. Now the issue has morphed into a question of whether or not consumers should be allowed to access content without their service providers slowing or blocking access to specific sites, and the issue of regulation is looking a lot different. Here’s a remarkably helpful timeline of every big moment in the argument to date.

In 2003 the FCC deregulated cable and DSL internet. This deregulation meant internet providers could now behave like regular, free market companies without intervention or restrictions from the Federal government. Great, right? Well, for the cable and DSL companies, yes. The result of this deregulation is a veritable monopoly by a few companies lording over the internet needs of the country, with no real motivation to improve their offerings or services. Without competition, there’s no incentive for providers to offer better service and keep their rates competitive. And for the Internet Service Providers (ISPs), well, it’s the ideal situation. We now have a few companies with a stranglehold on services, little competition, few choices for the consumer, and a situation that demands change.

Another problem was that ISPs took this deregulation as an opportunity to throttle bandwidth, control users’ access to data, and be generally schmucky. In 2008, Comcast blocked access to bittorrent sites, and then immediately denied doing so. The FCC finally stepped in and ordered that Comcast cease blocking bittorrent traffic (a case that Comcast, inexplicably, successfully appealed), but that didn’t stop them from choking speeds at the drop of a hat.

Comcast (and other providers) have been consistently guilty of throttling speeds when users access “too much” data. In the age of streaming entertainment, this becomes a huge liability and an endless annoyance to users. Net Neutrality would mean that they’d no longer be permitted to penalize (or charge a premium to) content creators like Netflix and Hulu, and that they’d no longer be able to slow connections for users who like their downloads fast and plentiful.

What's the big deal about the 26th?

So on Thursday, the FCC will vote on whether or not internet providers (include wireless internet providers) will be reclassified under Title II of the Communications Act of 1934. Title II would deem the providers to be “common carriers”, meaning companies like Comcast and AT&T would offer their services, “under license or authority provided by a regulatory body.” Title II states that common carriers can’t “make any unjust or unreasonable discrimination in charges, practices, classifications, regulations, facilities, or services.” You can see from this verbiage why Title II connects so well with Net Neutrality.

Proponents of the change say that it’s the only way the FCC can reliably and legally enforce rules protecting an open internet, with no designated fast or slow lanes for packet transfer service. Cable operators and phone companies say this will hurt their investments in the infrastructure needed to build out high-speed networks. But without competition to spur advances, there’s no incentive for them to improve infrastructures as it is. In other words, we’re not buying the cable companies’ Chicken Little claims. And neither are 4 MM others including FCC Chair Tom Wheeler.