Bowl Mania
Our Weekend Culinary Adventure—Curing Olives

Verizon, AT&T, and the iPhone

So Tuesday Verizon announced the launch of Apple's iPhone 4 on the Verizon network—surprising no one at all.

(Side note: following the news on Twitter is almost a sport, with tweets like "conference starts in 10 minutes" and "he's about to announce something big!" People, please!)

Of course, lots of folks (especially those living in San Francisco, where AT&T cellular coverage is the subject of much debate) have been waiting for iPhone's availability on the Verizon network. I don't need to cover the announcement or follow-up articles here; that's been done quite well by others, including these folks. What I find interesting is what lessons there are about how companies compete using the same basic product, and what it takes for a large company to partner with a smaller company.

Anything You Can Do, I Can Do Better

Verizon offers an iPhone. AT&T offers an iPhone. So how do you compete, when you and your competitor offer virtually the same product?

The first thing to do is to step back and review the complete customer experience. Verizon arguably has an advantage that transcends the device—their network. AT&T's responses notwithstanding, Verizon has been successful in asserting that "it's the network" and that their network provides better coverage than AT&T's network. AT&T has been responding that it has "the fastest network" but industry experts like Andrew Seybold will tell you that's a dangerous claim to make… since there are so many factors that determine the throughput of any given data connection.

Second, there are aspects of the service that can be used to differentiate: pricing, billing options, contract terms and bundled options are some examples. Verizon's "Friends and Family" service plan was a great differentiator, that had nothing to do with the products involved in using their service.

In Verizon's case, analysts have noted that Verizon will be offering support for "personal hotspots" with the iPhone; AT&T says it's "studying" the idea. Essentially, Verizon has bundled its "MiFi" capability, which allows a user to share a Wi-Fi connection among up to five devices. Adding support for Wi-Fi—and the ability to share a Wi-Fi connection—has other benefits (mobile operators are beginning to see the value in offloading data traffic to Wi-Fi hotspots), but in this context it creates a tangible difference between the AT&T service and the Verizon service.

Dancing with Elephants

Of course, supporting personal hotspots—or any partner-unique feature—puts a burden on the technology partner that has to be managed. There are both business and technical issues that have to be managed.

  • Who owns the intellectual property for a partner-specific feature?
  • If the larger partner funds the development of a unique feature, how do they pay for it?
  • What period of exclusivity does the partner get with their unique feature?
  • How does the smaller partner manage multiple, partner-specific software or hardware streams?
  • How does the smaller partner say "no" to some of the larger partner's requests?

Bigger partner-smaller partner relationships are common; executing them successfully is much less common. The bigger partner wants to take advantage of the smaller partner's ability to get features developed quickly. The smaller partner sees a path to a ready market via the bigger partner. Each partner can misunderstand the other partner's capabilities. Both partners can fail to anticipate the "downstream" activities that can cause a promising development to die before it ever makes it to the market.

Handling multi-stream software development can be accomplished with careful architecting of the software functionality into "base" functions and "partner-specific" extensions. Keeping this separation intact makes it easier to innovate on each side of the software stack, which reduces complexity in coding and downstream testing.

Handling the business concerns becomes easier when there's a clear framework for cooperation between the partners, and a clear understanding of how each party benefits from the relationship. I like to open these discussions by stating what I believe my partner expects to gain from the relationship, and then asking the partner what they think I expect to gain. Starting with the other party's point of view first makes it easier to uncover differences in goals and desired outcomes. Sharing these expectations up front also helps build trust with the partner—they see your willingness to share your views on how your company expects to gain from the relationship.

Saying No by Saying Yes

So what about saying "no"? This can be a tough one, for both parties. The bigger partner might think (and you might have encouraged them to think) that your development team can accomplish virtually anything and in no time. The smaller partner wants desperately to please the bigger partner and demonstrate the value they bring to the partnership. These going-in points of view can be the beginning of a relationship that disappoints both parties.

I like to say, "Say no by saying yes to something else". This starts with sharing your development roadmap with the customer. I wouldn't advise sharing your roadmap at the beginning of the relationship—you want to focus on delivering what you have, not what you've yet to build—but as the relationship proceeds the bigger partner will want to engage in a "what comes next" conversation. This is where the roadmap helps, by doing a couple of things.

  • It communicates a vision. Sometimes, the bigger partner wants to work with you because, frankly, they feel like they don't understand the market as well as you. Your product roadmap—and the vision behind it—communicates this understanding well.
  • It outlines what will eventually be delivered. Often times, what the bigger partner wants to know is whether you ever plan to deliver a capability; when is something that can be discussed later. Smaller partners often confuse "will you ever" with "will you" and presume the time frame is "now".
  • It sets a context for negotiation. Maybe the bigger partner wants a capability delivered one quarter earlier. Seeing the entire roadmap leads to a discussion of trade-off's: what are you willing to take later, in order to get that other capability now? In the absence of a roadmap, the bigger partner has no sense of the costs implied in asking for more, sooner.

There are still times where the bigger partner seems to be asking for more than you can comfortably deliver. How do you respond?

One point to realize is that there are lots of "actors" on the bigger partner's side, and they're not all equal. For instance, it's common to have members of the bigger partner's technical team involved in the discussion, and they will often ask for particular features. Maybe they're asking you to solve the problems they've had trouble handling. Maybe they're testing you. The important point is that they are not directly responsible for the bigger partner's product success. You have to know who owns the success of the envisioned product, and involve that person in the discussion. Because the discussion that needs to take place is all about trade-off's: time to market vs. functionality vs. resource costs. And you have to have the conversation with the person responsible for making those choices.

As one example, I was working on the rollout of a mobility service with a large systems integrator partner. We had worked out the fundamental product requirements and were busy executing on them. One person in the partner's organization wanted to know about our plans for SOAP and Web Services integration. When I dug into the question, I saw that this person was asking us to re-develop our entire "back end" infrastructure to allow for "seamless" integration with the partner's business processes and logic. The partner hadn't done the SOAP or Web Services work either, but this person wanted to be ready once they had. It took many conversations, but I was able to gather support from product owners on the partner's side to convince this requester that supporting SOAP and Web Services was something that could wait.

Don't Stomp on Your Dance Partner

Working with a partner substantially larger (or smaller) than you is something that's not going out of style anytime soon. So it's definitely worth knowing how to successfully engage with that partner. Smaller partners need to understand how products and services flow from development through testing, operations, deployment, and eventually sales. Larger partners need to understand where smaller partners can and can't help to innovate.

Over time, we'll see how well AT&T and Verizon respectively are able to partner with Apple to bring new customers to their services, and how well Apple partners with these and other mobile operators to expand the market for its smartphones and tablets.  Meanwhile, be smart about how your approach your partnerships and you'll be more successful in the end!


Feed You can follow this conversation by subscribing to the comment feed for this post.

The comments to this entry are closed.