Archive for January 2013
Balancing tradeoffs across different customers
Balancing the needs of different types of customers within a single product is an incredibly difficult challenge in product design. Most every product faces this in the course of choosing features or implementation. Designing products in a changing world with changing definitions of success can be a real challenge, but there are a number of creative approaches that can be used.
Tradeoffs across different customers
I was lucky enough this recently to spend some time with the CEO of a growing company (> 150 developers). The company faces a constant struggle in their product line over how to balance the feature demands of end users “versus” IT professionals. This is an especially acute challenge in a growing company where resources are limited and winning those early paying customers is critical.
The use of “versus” is intentional. Most of the time we view these trade-offs as binary, either/or. That’s the nature of the engineering view of a challenge like this. In stark contrast, the sales/marketing view is often an “and” where the most desired end-state is to meet the needs of every type of customer. In practice, the reality of what needs to be done and what can be done is much more subtle.
Because IT pro and end-users are often viewed as working against each other, this is natural (By the way, I’ve never been a fan of the term user or end-user – a wise program manager I had the pleasure of working with once pointed out “only one other industry refers to customers as users, let’s not follow their lead.”) IT Pros think end-users seem to exist to cause information leaks and network slow-downs. End-users, let’s just call them people or humans, think IT is there to prevent any work or progress from happening. Again, reality is less extreme.
But we face many tradeoffs in developing feature lists, and thus product plans, all the time. In fact for just about any software product/service these days you can easily list a variety of customer types:
- Humans. These are the broad set of people who will use your product. Generally you don’t assume any extreme level product usage skills. These are typical customers. Of course all other customers are human too :-) The challenge each faces is representing their constituency and role beyond that of typical customer.
- IT Pros. For most tech products, IT Pros are the folks that deploy, purchase, or manage the product. They might also provide infrastructure and hardware required to use a product or service. IT Pros also champion the people in the organizations they support.
- Developers. Developers contribute add-ins or consume APIs to develop customized solutions. For many products, developers form a critical part of the ecosystem and often create the stickiness associated with a successful product.
- Power users/enthusiasts. These folks know the ins and outs of a product. Often they teach others to use a product, staff the newsgroups or self-help forums, write blogs and articles about your product. These are your fans. Power users also have feature requests (demands!) for more control, more customization and so on. Notice right away how this could work against IT Pros who want less of those or Humans who might be perplexed by such features.
- Channel partners. Many products are sold direct to humans or IT. On the other hand there are a large number of products where there are intermediate partners who are required to sell, service, or otherwise transact with paying customers. In an ad-supported product these are your advertisers. This provides another tension point our industry commonly talks about—the aspects of ads in apps and web sites which are important to the channel but might not be valued as much by Humans, as an example.
- Markets. Many products aim to meet the needs of a global customer base. Even in a global economy, there are major differences in features and scenarios around the world.
Not every product has every potential customer type and above is not a complete list. Often there is overlap; for example, most IT Pros are often enthusiasts and/or power users. The term “persona” often gets used to represent a customer type. That is a good tool, but rather than focus on the details of the person, just defining a broad category is enough when planning and scoping the product. The persona comes later in the process.
In industries defined by a combination of physical goods and physical distribution channels, products are segmented and offered with different attributes at different prices for different customers. Software and hardware products that intermix, or don’t distinguish between, both work and personal life, and often switch between those many times throughout a day, pose a special challenge to product designers (and marketers). Working within this consumerization trend motivated this post.
Relative to designing for such a scenario, a product plan might find itself in a tough spot because of challenges in the plan or approach:
- Focus nearly exclusively on one target customer type. Sometimes the approach is to just draw a line in the sand and say “we’re all about end-users”. Often this is the default most products take. In some products you can see a clear view of who the target is and a clear strategy. There are then “some features” aimed at appeasing other potential customer types. You might rationalize this by combining customer types, by saying something like “Developers are just humans who can code” for example.
- Do a little bit everywhere. There might be a case where a product is not quite deliberate and the organization or up front resource allocations end up dictating how much each type of customer gets. For example if you allocate a few developers to each segment then the let folks plan independently, the chances of features holding together well are reduced. More likely, features might end up competing or conflicting as they are developed.
- Have a plan (and some execution) and then realize late in the process you’re missing a customer. We have talked about the need to bridge the engineering and marketing efforts. In some plans there are engineering plans that don’t get buy off and as the product starts to come together the inevitable panic of “there are no features for X” where X is a customer type not receiving enough love. Meetings. Panic. Last minute changes. Doesn’t work.
The key to resolving tradeoffs is to know you’re making them up front. Product development is inherently about tradeoffs in many dimensions—in fact product development can be viewed as a series of tradeoffs and the choices made relative to those tradeoffs.
Planning to make choices
A recurring theme with this blog will be to surface issues while you are planning and to acknowledge up front that the plan is going to make choices about what to do. Rather than think of this as a micro-management waterfall approach, the team needs to arrive at principles that guide decision making every day for the team. Principles and plans work better than budgets, organizations, or requirements—principles are what smart and creative people can use effectively as a tool to address the tradeoffs inherent in product development. Tools like budgets and requirements are more like weapons people can use against other parts of the team to prevent work from happening. Principles tell the team the starting point and the end point and offer guidelines for how to make choices as the path to the end point is developed.
As an example, consider a budget that you establish that says how many resources will go to Humans and how many will go to IT Pros. Sounds great on paper. It seems like the easy way up front to decide how to address the conflict or tension.
This can backfire because it is not a holistic plan for what the product will be. In fact is almost prevents the holistic plan from happening because the first choice you make is to partition resources. The leaders of those resources are then incented to just make a plan for their efforts rather than think about the whole of the project. That isn’t evil or malicious, just a natural outcome of resource allocation and accountability.
This same dynamic might occur if you partition the team into front end/back end, or UI/service for example. Such a structure is fine, but should be done in the context of a holistic plan. Putting in place such a structure before there is a plan and hoping the plan resolves difficult problems can be difficult.
Conflict and tension are actually created by a resource budgeting approach as people naturally defer choices and decision to the management and resource allocation tools, not a collaborative product plan.
Approach
Building on the previous post about developing a framework, one can use these same tools as a way of cross-checking the plan against customer types.
We talked about a tool where you identify feature ideas and assign costs as a way to arrive at a holistic view of the product. This tool can be used with different folks in the org or even customers/partners.
Once you have arrived at a list you can take this a step further. A good idea is to refine the list of proposed ideas with your own knowledge of feature descriptions and granularity. What is helpful at this point is to develop a catalog of features that you feel could be effectively communicated to customers broadly.
For example for a very large product these would be the sessions you might give at a customer workshop describing the product. For a first generation product these features would be the product information page on a web site or even the table of contents of the product overview document you might give to a member of the press.
The way to gain an understanding of the tradeoffs you are making relative to customer types is to take the features and align them with the different customer types you have identified. This can easily be done by a spreadsheet or even a list on a whiteboard.
When you’re done every feature is listed once – you don’t give yourself credit in more than one place for a feature. This forces you to really decide who values a feature the most. Features will naturally fall into place. For example, management features will fall to IT Pros or ease of use to end-users.
Most products will show the inherent “tilt” towards a customer type during this phase. You then step back as a team and ask yourself if you’ve made the right tradeoffs or not.
Then iterate and make sure you are really delivering the holistic plan. Once you get closer to a holistic plan you can allocate resources. Iteration doesn’t stop there of course. You can move forward with a more refined view of the plan and the resources. Implementation then progresses based on the resources at hand, which is better than ideation and planning based on resources. Unlike a characteristic waterfall approach, a good planning process is a process of iteration, convergence, and parallel efforts across disciplines.
Design tradeoffs
The above all sounds good, probably. If you do the above you can solve the resource allocation and overall scope of the product relative to different types of customers. It doesn’t, however, get to the heart of one really hard problem. What to do when customer needs conflict?
One thing to do is bury your head in the sand and just say there is no conflict. That is saying, for example, that end-users will value features missing that IT removed or that IT will just get over themselves and not mind arbitrary extensions being loaded on the device. That doesn’t work of course.
Because product development does not end—a release is just a point in time, which is even more so on today’s continuous product cycles—you do need to get comfortable not doing everything for everyone every release. There is always a next release. So resolving design tradeoffs needs to be about having a set of principles and a product architecture that you can build on.
This is where understanding where your own product is going is crucial, a longer term strategic view. Most products when they are new receive a combination of praise and criticism from power users, as one example. If the scenario or problem solved is compelling, power users will praise the product. They are, generally, quick to offer up suggestions and feedback for how to add flexibility or more features. That’s exciting.
In the process of designing the product, a key responsibility for the designer is to know where a design is heading. How will you know how to add more power and control? If you don’t have ideas while designing the product in the first place you might be designing yourself into a hole. Famously, copy/paste were missing from smartphones when first released. Even with a new touch design language, designers clearly understood where this would go. That was important and made it easy to introduce without a major shift in the overall ease of use that was the hallmark of the design. This could have easily been a conflict between power and ease of use.
Code architecture or architectural approaches play a key part in how you think about where you are today relative to where you are going. Many of the architectural differences between the different OS platforms we see today compared to how an OS looked 10 years ago result from making tradeoffs in the architecture. App stores, sandboxing, APIs with brokers are all about tilting the architecture towards security, battery life, and end-user safety.
We look at these changes in architecture today and compare them to where we came from and can easily see the difference. But think about the debates and planning that took place—this was a big change in approach. It was not easy for those making platforms to make these architectural tradeoffs in such a new way. Creatively addressing new requirements is a key part of understanding your product evolution over time.
An important tool is having a set of product principles–design language, architectural framework, and customer value proposition. These principles not only guide the development team but make it easy to articulate the tradeoffs made to customers when you’re done. That doesn’t make the dialog easy or even get folks to agree with the choices you make. But you’re having a conversation informed by what your product is trying to do.
An amazing change in happening in our industry today with “BYOD” or bring your own devices to work. This is a whole new level of design tradeoff the industry is facing. Since the late 1990’s the focus on administration has been to “lock down” or “control” computing devices. That worked well given the choices and challenges faced.
Consumers now can bring their own devices to work, work from home, or find ways of doing work outside the scope of the corporate network/software/device. This doesn’t change the security, IP, and safety needs of a corporation or government agency. It does change the decision framework of IT. Their internal clients have choices and how those choices overlay with the design tradeoffs in products is very interesting.
Just as APIs and OS capabilities are changing, and perhaps resetting expectations of some customer types, the way devices and software are managed are changing architecturally. As you’re planning the product, developing an architectural approach that plays out in a forward looking way is going to be a key part of resolving the design tradeoffs.
This is the engineer part of resolving tradeoffs—sometimes it is not just coming up with features, but new architectural approaches can put you on a new trajectory. That new trajectory defines new ways to design products for many types of customers.
The only thing you know for sure in addressing customer tradeoffs is that there is no right answer that always pleases all customers. That’s the nature of appealing to multiple customer types. That’s why product development is also a social science.
An Example: the enterprise challenge
These days, one of the most challenging product design debates centers on how one balances the needs of enterprise IT and the community of people, humans, using products within an enterprise. There is a major shift going on in our industry with the wave of consumer products able to fulfill scenarios outside of the control IT.
The dramatic change is decidedly not in the enterprise need to secure the digital assets of an organization or to maintain the integrity of corporate networks or to even manage the overall usage of corporate resources (balancing work and non-work). These requirements are not only still there, but in a world where a single leak of customer or financial data can make international news or the interest of regulatory bodies these requirements are more intense than ever.
The dramatic change, however, is in the ability for people within an enterprise to easily acquire tools to accomplish the work they need. In another era, obtaining servers, licensing software, getting it on site and running were all tasks that required IT sponsorship and often resources. Today tools such as cloud storage, peer to peer communications, CRM, or even commerce are just a few clicks away and require nothing more than a corporate credit card, if that.
The only policing mechanism that can be deployed “against” these tools is a policy approach. While one can block TCP/IP ports or suspicious network traffic (and certainly block downloaded client code on managed PCs), even this is challenging. Network access itself is easily obtained via a WiFi/4G access point or phone as hotspot.
The traditional approaches of locking down a device simply don’t work. In a world of mobile devices and perhaps even multiple operating systems, there isn’t a clear focal point for these lock down efforts and certainly not even a single implementation that is possible.
Where some might see this as freedom, others might see this as chaos. Smart product design efforts see an opportunity. There’s an opportunity to design products that embrace this challenge and opt to provide an architecture for IT to get done what is required of them and at the same time making it easy for people to discover and spread tools to other coworkers that solve the business challenges they face.
The design challenge is about defining a new architecture that takes into account the reality that you can design yourself into a corner if you go too far in either direction. You can focus too much on empowering people and face either a policy choice from IT or worse an active campaign against your product from the enterprise analyst community. You can focus too much on IT and your product might enable IT to turn a cool product into a locked down or customized experience that drives end-users to your competition, which is only a click away.
This is where design principles can come into play. What is the current implementation of management—what has been implemented by IT organizations that has might have lowered the satisfaction of corporate computing relative to home computing or BYOD, for example? Efforts like excessive logon scripts or complex network access requirements that keep people from using the network and favoring the path of least resistance, perhaps? Or perhaps a customized user experience for a product that is also used on home PCs and thus “different” at home and work, driving more use of the home PC for work?
Given an environment like that what is an architecture that takes into account the downsides of existing approaches to enterprise management and creates a more favorable experience while maintaining security, knowing that options abound?
Can a device be managed without changing the user experience? Can a software product be locked down relative to critical functions to reduce support calls without IT getting between the work that needs to be done and the employee?
These are the sorts of questions one needs to raise in reconciling the apparently contradictory needs of IT and people using modern products and services.
Really diving into these as you design your product has the potential to develop a real competitive advantage for your product and service.
–Steven
###
Managing through disagreement
In the course of figuring out what to do on a project (plan, code, collaborate, marketing, …) inevitably you will get to a point where two parties (two people, two teams, two disciplines) don’t agree. Figuring out how to move forward is not only essential, but is something that can make or break a team or project.
Focusing a discussion on disagreement in the abstract is a good way to approach this, rather than using specific examples. This allows the dynamics to be discussed here without the distractions of picking sides. When it comes to disagreements, even the specifics are usually much less important than the overall context in which the disagreement is taking place. More often than not, a focus on specifics tends to hide what is really the root of a disagreement.
This post was suggested by a reader as a topic worth discussing. Suggestions are welcome and I’m always on the lookout for comments and tweets with suggestions or email me at steven@learningbyshipping.com, perhaps with something going on at your organization right now that is a generally interesting topic (specifics always removed).
Organization
Organization plays a key role in the context of building consensus (more on organization in a follow up post). Is your team managed step by step through a hierarchy, deferring to the management chain? Is your team one where the most senior manager gets involved in many choices? Is your team dominated by a strong de facto leader that leads from within the team? Is your team a small group of peers that seem to usually agree on everything? Is your team subject to swoop and poop from outside, bringing disagreement to you? There are quite a few ways that disagreements can surface and/or get resolved and those are a few.
The first step in working through disagreement is to know how your team is structured to make choices, which might be different than the org chart. You want to know not just how you want to decide things, but how do others in all 360 degrees expect to resolve things.
The 360 degree view has been something I have often worked through (and certainly not perfectly). In a team with a plan and a strong organization, it is the organization working with a decision framework, the plan, that decides. Those new to the team or even those on other teams often see a team operating this way and assume a hierarchical or top down model—otherwise how could things appear to work and stay on track with a large project.
In practice what that means is that there is a mismatch in how to handle disagreement. Some assume that you have to go to the top and “get things changed”, while folks at the top are saying “did you talk to the people doing the work.” This type of cultural mismatch is the first thing to overcome. On a team of empowered creative folks, they have gone to great lengths to say what they will be doing and how they will decide what is yet to be discovered. That’s always been enough for me.
Roles and responsibilities in an organization, not hierarchy, are also important. Are disagreements between people within the same discipline or across disciplines? Often agreements can be settled by recognition of where the responsibility rests. For example, in projects with user interface many people can have opinions about the UI but the team should be operating with acknowledgement that the accountability rests with the discipline (design, program management) that is doing the work to design the UI. Having a clear view of how specialties work in the organization is an important part of knowing how disagreements will be resolved.
Organization can cause disagreement to flourish in two main ways. First, management can structure things such that goals and/or accountability are unclear. This means things need to be integrated or reconciled “up” where there is always less information/data, thus driving meetings, debate, and campaigning for decisions. Second, members of the team can fail to defer to the empowerment and decision making structure in place (plans, disciplines, accountability). This is a case where disagreement exists when individuals on the team could take time to step back and let the organization do the work.
These organizational elements are an important part of the context around disagreements.
Context
What is it that makes disagreement so pervasive and so difficult to work through? Are there really so many arguments to be had while building a product or service once you decide what can and should be built?
I’ve always been fascinated by the dynamic of how something turns into a big decision to be made. For me, work is progressing and sometimes things come up that are hard or unforeseen. Then all of a sudden there is a crisis and something needs to be decided and that decision has expanded to involve a lot of people.
Knowing the context is always the most important first step. The following are some examples of reasons or context behind disagreement:
Decision or an argument. A first consideration is if there is truly a decision to be made or what is really going on is an argument. What this means is to ask if someone questioning your general approach or is this a real challenge to the choices you are making. It is only to your advantage to engage with members of the team who might have a different point of view. You don’t have to accept it or escalate into a fight, but it is always good for everyone on the project to be heard.
Naysayers. Sometimes a decision gets created that is not really all that important, but is being used to drive a wedge for any variety of reasons. Often these look like “let’s take a step back and ask the following question.” So you thought you were having a discussion about a schedule estimate and the next thing you know you are in the weeds debating agile v. waterfall. You have to ask yourself if the real issue is the meta-issue, a lack of faith in everything going on, or if you really have something that is the source of a disagreement.
First of many. There are times when points of difference get raised in a “death by 1000 cuts” sort of way. In other words you might find yourself disagreeing over a specific topic but as you’re talking (constructively) it becomes clear that this is going to be the first of at least a few disagreements. Folks might use this approach to test the waters or to probe for a weakness overall. An approach here is to work to smoke out all the disagreements so you can have a discussion with the full context.
Symbolic or material. Sometimes a disagreement is really an effort to raise a more symbolic disagreement with the broader context of the project. Helping to work through and discuss how material a given disagreement is to the whole project is especially important here. In this context, a disagreement can turn into a broader view of two parties not connecting.
Accountability. Ultimately disagreement needs to factor in accountability. If the first step of a disagreement is “who gets to decide” it is likely the answer will itself become a disagreement. Almost all disagreements I have been part of scream out the person who should be deciding. If it doesn’t the question is really more about accountability—not who should make a specific choice, but who is accountable for a broader set of issues. Is that person not doing a great job incorporating lots of viewpoints and information? Did that person not enroll everyone in a broader framework?
Context is everything. In the heat of a disagreement people, especially for engineers who tend to distill things into concrete facts or algorithms, will often get very focused on the details of winning the argument. It is a good idea to understand the context of the disagreement before trying to win on the merits.
What can go wrong?
As you’re working through a disagreement, there might be a few patterns you run across that are used to resolve the disagreement—patterns that might not be the most productive.
The key thing is to keep the dialog focused on the context of a choice. In a sense, what I think everyone knows is that any disagreement free of context can have a different outcome than if considered in the context. A classic is “add this feature.” Absent the context of schedule, resources, and most importantly the holistic view of a plan/product, almost any feature sounds like a good one to add or any change seems reasonable. The flip side is that just about everyone sounds like an idiot arguing against security, performance, quality absent the context that an engineer might have. No one sounds smart arguing against a revenue opportunity, until you consider the cost, alternatives, and so on.
There are patterns that are bad ways to resolve disagreement because the technique removes the context:
Single choice. Sometimes when there is a disagreement, something that seemed small starts to take on a life of its own. You come to a meeting and you’re all of a sudden having a debate over the color of tooltips in a toolbar (true story) when that is not really the disagreement as all. What has happened is a disagreement over a broad set of issues has morphed into what appears to be a single choice. The context was lost and a complex, multi-dimensional problem space has been replaced by one, seemingly, trivial option.
Escalation. Sometimes disagreements get created as a way to get in front of the boss or as a way to encourage the boss to get in front of the other party. This type of disagreement is never good and my first reaction is to pull back and “de-escalate” like cops do on reality shows. Something I have always tried to practice is the notion that to escalate is to fail. But the real challenge with escalating a disagreement is that the context and knowledge about a situation is reduced as you move up the management chain, so escalation is really a way of saying “decide with less information.” There are subtleties and nuance to this (for example if you haven’t done your work to incorporate the context from outside your specialty in creating a plan). New information can change things and the question is whether you are being too heads down to incorporate new information. The key is that once you escalate you lose the context of the choice. Similarly, to pull a decision up (the organization) creates the same dynamic of deciding with less information than might be available.
Decision maker. One way to remove the context from a disagreement is to introduce a debate over who gets to decide, as mentioned above. I’ve been part of all sorts of “tools” that are supposed to help you decide—tables of who reviews choices, approves things, or “responsibility assignment matrices.” As well-intentioned as these are they don’t really scale and they encourage all choices to get broken out into elaborate decision-making processes. At some point you can rationally ask how to even decide what decisions go through a process like this or is this an attempt to circumvent accountability or an attempt to game the system.
Accountability shift. Accountability gets to the heart of most disagreements. Those disagreeing feel on the hook, accountable, for some outcome and the choice being discussed impacts the potential for achieving the assigned goal. By shifting the dialog from the disagreement to accountability, things get emotional very quickly. The discussion turns into talk of “failure” which is a lot to place on the shoulder of a single choice in a complex product.
Tools and approaches
In practice the tools to reconcile disagreements are rather personal—they rely on the skills, tone, and temperament of the individuals. Most everyone can lose their temper or go silent (essentially the same thing). Most everyone has sent a late night mail they regret (subject line, “thoughts”). Most everyone has behaved the way they criticized someone for behaving. I’m there with you and don’t have magic answers to resolving disagreements. Here are a few tools I have used:
Expertise. Where is the most expertise? As a general rule, too often decisions are made in meetings where people are presenting cases and someone is in the middle trying to referee or decide. At that moment, a decision is being made by a committee or by a group, yet the people that have the expertise might not even be in the room. As a general practice, pushing decisions to those that know the most yields better decisions. Many times teams convince themselves that there are implications that go beyond the expertise (“yes this might be a security problem but the business has different issues”). The best thing then is to figure out how this type of context is not making it to the domain experts—what was missing from the day to day flow of information that got a team in a situation to begin with?
Plan. Most disagreements are essentially disagreements with a broader view—at the highest level or at the level of what a feature or marketing message should accomplish at the core. In other words, while the discussion might be about a specific, it is a disagreement about a broader theme. I return back to the plan (the one you got buy-in about because you talked about it broadly). I try to understand what has changed or what have we learned since the plan. Plans are dynamic of course. But one needs to be careful about changing direction without a real change in the business or product landscape. If you do change plans, you need to think hard about the relationship of one change to the big picture.
Culture. The best tool for resolving disagreements is one you have to put in place upstream, which is a culture that allows and respects the decisions being made by the right people. Developers might not like the advertising, but marketing people decide that. Marketing might not like the wording of a license, but that’s a decision for lawyers to make. But because a team should be operating with a shared view of customers, the decisions should be ones made outside of silos of expertise or narrow views of success. There’s definitely magic in there and in a big project achieving this uniformly is extremely difficult, at best. The tool everyone should ask for in a culture is a management chain that supports the culture. It isn’t about being “backed” in a decision but about being consistent in the notion of delegation and accountability.
Accountability. Related to culture is the notion of accountability. Rather than saying “test is accountable for quality” the tool is really for management to reinforce that everyone is ultimately responsible for the overall result. If something is successful you can bet that everyone on the team will feel they contributed to the success. There’s nothing stopping the team from acting that way while the product is under development.
When to say when. Finally, the best tool any individual can have in the course of a disagreement is knowing when to say when. Projects are marathons (no matter how long a particular coding sprint might be). If you choose to turn every decision into the most important and biggest one, you’ll run out of reserves long before the finish line.
One final consideration is if you agree to disagree then you have to mean it. It means you can’t remind folks at every opportunity that you saw things differently. It also means you’re tabling the disagreement for good and that you’re not inadvertently establishing a dreaded accountability dodge or told you so for later on.
There are innumerable decisions in any project—each person, then each team, then teams, and more each make choices dozens of times a day. Every line of code, every word in a spec, every automated test, every part of a plan, every data sheet, PR script, and more are decisions.
People tend to forget this in the heat of the moment. Time heals, and forgets, most every small decision in a project. In fact, I would bet that any disagreement you are dealing with at this moment will be a distant memory and chances of it determining success and failure of your project are small when viewed in the context of all the work, and decisions, yet to be done. Om.
–Steven
Reminder – please see the recently added disclosure page.
###
Learning from Competition
Gotcha. Traitor. Snicker. Those were some of the reactions when people discovered that I was using an iPhone. I stand before you accused of using a competitor’s [sic] product and I plead guilty.
Moving beyond the gotcha blogs, there’s an actual reason for using technology products and services other than the ones you make (or happen to be made by the company where you work/ed). I think everyone knows that, even a thousand tweets later. The approach in many industries to downplay or even become hostile to the competition are well-documented and studied, and generally conclude that experiencing the competition is a good thing.
Learning from the competition is not just required of all product development folks, but can also be somewhat of a skill worth honing. Let’s look at the ins and outs of using a competitive product.
Why?
Obviously you should use a competitive product. You should know what you’re up against when a consumer (or business) ultimately faces a buying decision. They will weigh a wide array of factors and you should be aware of those not only for the purposes of sales and marketing but when you are designing your products.
It is easy to fall into the trap of checklists or cloning competitive products and so that might be why you follow the competition. That’s a weak way to compete. Part of planning your product/service is establishing your unique value proposition—is it features, pricing, implementation or execution for example?
Simply being the same as your competitor that might be more established is not good enough and so knowing the competition for the sake of skimming their value proposition won’t work. Generally speaking, just adding the cool thing from a competitor at the last minute to your product’s plan is not going to work well for customers and will be readily transparent. That’s checklist product development.
Product development is a complex endeavor. There is no magic. Worse than that, most people making products in a “category” are pulling insights, ideas, and technologies from the same sources. What separates wildly successful products from distant number two products can often be just a few of thousands of choices.
Studying your competitor, well, gives you a chance to evaluate your choices in an entirely different context. When you make a product choice you are making it in the context of your company, strategy, business model, and people/talents. What if you change some of those? That is what knowing the competition allows you to do, and basically for free (no consultants or top secret research).
What does it mean to study the competition well? What are some common mistakes made when studying the competition?
Common Mistakes
Even when you study the competition, there are some techniques that are often employed, and with the best of intentions. There are ways of executing on a competitive analysis that leave some information on the table.
Worse, it is possible to execute on a competitive analysis from a dismissive or get this over with posture that takes away what is perhaps the most valuable source of information in forward looking product design.
While there are many potential challenges, here are a couple of examples of patterns I’ve seen.
- Using the product in a lightweight manner. All too often analyzing the competition itself becomes a checklist work item. Go to the store and play with it for a few minutes. Maybe ask a friend or neighbor what they think. The usage of a competitive product needs to be in depth and over time. You need to use the product like it is your primary product and not switch or fall back to your old way of working. Often this is weeks or more of usage. Even as a reviewer this applies. Walt Mossberg famously took an iPad on a 10 day trip to France—no laptop at all. That’s how to use a product.
- Thinking like yourself, not the competition. When using a competitive product you need to use it like it was intended to be used by the designers. Don’t get the product and use the customization tools to morph it into the familiar. Even if a product has a mode to make it work like the familiar (as a competitive bridge they offer) don’t use it. Use native file formats. Use defaults in the UI and functionality. Follow the designed workflow. They key is to let loose of your muscle memory and develop new memory.
- Betting competitors act similarly (or even rationally). If you think like a competitor you have to make future decisions like they might. Of course you can’t really do that or really know and this is where product intuition comes to mind (and also why blogs predicting product directions are often off the mark). You have to really wrap yourself around the culture, constraints, resources, and more of a competitor. The reality is that your competitor is not going “fix” their product to turn it into your product. So then the question is what would a competitors do in their context, not what would you do if you were designing the follow-on product in your context. This might actually feel irrational to you. One of the most classic examples of this is whether or not the Mac OS should have been licensed to other PC makers or not. Arguments could be made either way, both then and now. But what is right or assumed in one context simply doesn’t make sense in another. That context can also include a time dimension where the answer actually changes.
- Assume the world is static. Even after you’ve reviewed a competitor through usage you might feel confident because they are missing some features or might have done some things poorly. That’s a static view of the world. Keep in mind analyzing the competition is a two-way street. If you noticed a weakness there’s a really good chance the competitor knew about it. When everyone pointed out that a phone was missing copy/paste, don’t make a mistake thinking that was news to the development team and would remain a competitive advantage.
Approaches
There’s a reason Patton often made reference to Thucydides treatise on the History of the Peloponnesian War. It is a thorough and thoughtful analysis that goes beyond who won which battles but gets inside the minds of the men, the culture, and the thought processes. Competing in business is not war and should not be treated as such, either literally or as a metaphor (the stakes are relatively insignificant and business is an endless series of skirmishes and battles rather than aiming for an ‘end’, at the very least). However, the idea of being thoughtful and understanding tactics, decision making, resource allocation, and more are important.
There are a few techniques that are often used in conjunction with using the product. The most important thing is of course to use the product and to adopt it as your primary tool for all the uses it was intended in the manner in which it was intended. With that raw data, there are number of potential tools for sharing that learning:
- Feature comparisons. The most obvious tool is to make a long list of features and compare products. This works well for some folks and especially when handed to customers. It is also the least useful in product design. A feature checklist is only as good as the features you put on it. We all know how easy it is to make a product look feature rich or feature poor simply by picking the right set of features to check off. You can even pick weird measures for whether a feature is in or not—you could have a “WiFi” check item or you could make it “WiFi a/b/g/n” and change who won or lost. You can also lead to a false conclusion if you try to score or just count features—it is doubling the error rate of your check list because you’re doubly-assuming your context.
- SWOT. A common “single slide” approach to competitors is to distill down competition into something like strengths, weaknesses, opportunities, threats. These are very hard to do well, again because of the context, but by including all of these you force yourself to confront your own product shortcoming and missteps. Personally, I don’t like the use of “threats” because it starts to conjure up war and sports metaphors but you can think of them as risks that customers won’t choose your product/service. SWOT is often used by the marketing team because you can intermix near term tactics in the marketplace (opportunities).
- Scenario comparisons. A nice way to take a more end-to-end approach to competitive analysis is to consider more complete scenarios. If you’re testing for battery life then don’t just play a movie, but play a movie with the radios on and an active mailbox, as an example. As with everything, it is important to pick scenarios that are truly representative of what a product was designed to do and how it was designed to do it, not how your product/service does. Measuring a scenario comparison could involve clicks/gestures, clock time, resource consumption, and more.
- Competitive review or blog. My favorite test of really getting in the mind of the competitor is to challenge yourself to review your own product as though you were the competitor. Alternatively, you could write a press release or blog for a competitive product—the product that competes with you. I remember once writing a whole “press kit” for what became Visual C++ as though I were the Borland C++ team. It was great fun. Rather than focus on Windows (3.0!) development, I focused on compiler speed, code size, array of command line options, and more. Those were the things that Borland would focus on. I then ripped into Visual C++ as a Borland person, highlighting what options were missing, the slowness of the tools, and so on. Even though VC++ 1.0 had a Windows dev environment, resource editor, class library and more—all assets relative to Borland.
Of course no matter what your approach, be sure to write down your work and analysis (writing is thinking!) and share it with the team (learning by sharing).
Be Obsessed
Those are a few common pitfalls and approaches to competitive analysis. There are many more. Feel free to share your favorite approaches in the comments.
Finally, studying the competition is the job of everyone on a team. Importantly, the people doing the work need to study the competition. It is not a job for a staff function or those outside product development. Management studies the competition not just receives reports on the competition. Experts in domains that are parts of a product should drill into the details of the competition (hardware, software, subsystems, peripherals, APIs, etc.)
Be obsessed with the competition. Always. This has never been truer than the fast paced and dynamic world of products where the flow of information is instant and the scale and complexity are greater than ever before.
–Steven
PS: My plan was not to publish so frequently/rapidly, but even in my old MS blog if something came up that was so timely relative to the ongoing dialog, I’d do a quick post. I’m still going to pace myself :-)
###
Learning by Sharing: Snark-free CES 2013 observations
Wheels up, returning from CES. Seems like a good time to reflect and share some of my observations.
Sharing raw data is an important part of building a strong cohesive team. Raw data allows everyone on a team to see the inputs and thus map from there to the conclusions, whether those are new plans or course corrections to existing plans.
This post shares some observations about CES but first provides some context and practices for the ins and outs of trip reports in the context of product development.
Why do trip reports?
From the earliest days of business travel, my managers have required a trip report in exchange for the privilege of taking a trip at company expense. Whether you are a manager or not, sharing your observations and learnings from a trip (site visit, customer roundtable, trade show, conference) is a way of contributing to the shared understanding of products and technologies.
A report is just that—a collection of words and artifacts—and by itself it does not represent the follow up actions as those need to come from a process of taking the data from multiple perspectives and spending time thinking through implications. In fact, a point of failure in product development is over-reacting to the immediacy of a single trip report or point of view (no matter who on the team wrote the report). Those are anecdotes and need more work to turn them into actions like changing plans or features.
Practices
There’s no right way to create a report. More often than not the format, structure, and detail of a report should follow from the type of event. Do you organize by type of technology or by vendor, by customer or customer theme, by conference session or by technical subsystem, and so on?
Reports also don’t need to be short, especially if the trip was filled with information. If you want to offer a distillation at the bullet point level then there are a couple of options. For a public event you can often cite a blog or article (or two) that seems to match your perspectives. For a confidential event you should still do a detailed report and distribute as appropriate, but consider an oral version for members of the team. Bullet points can be good on their own to make key points and also may serve as an outline for the body of the report. The downside of providing only bullet points is that it might not share enough of the raw data and folks might think of what you shared more as conclusions. Keep in mind that the time spent writing the report is also time spent thinking more deeply about what you experienced.
I personally value the use of pictures quite a bit. For site visits showing the artifacts (example app screens, paper based systems, use of devices in context, photos of the physical environment) can be super helpful to highlight what you saw. For conferences, if there is a great slide or graphic from a session, showing that can help a great deal. And for tradeshows, showing off products is super fun. Video of course can be cool but introduces complexity in sharing in some formats.
There’s often a discussion on how much hyperlinking to do in a report (links to presentation PPTs, videos, or product information for example). It really depends on the need the readers/target will have to seek even more information. Obviously you should always be prepared to provide more information, but I don’t think it is a best practice for your report to be filled with blue underlines or missing data because everything is a click away. If you’re tracking hardware, for example, and some spec (wt, mHz, watt) is important then just include that in the report.
There are two aspects to confidentiality / intellectual property to respect when writing a report. First, always be careful to report on things you are permitted to write down and report on. You should ask permission for any photos (at customer sites or conferences, and even some tradeshow booths). Second, when you distribute your report make sure you are working within company policy on the way information is shared.
Whether you use email, attachments, a file share, OneNote on SkyDrive (to share with a small group), or a blog (internally hosted) really depends on your org’s culture. The blog format is great because then you have one place with all your reports so you can always know where they are no matter what type of report. The key is to just make sure, without spamming people, that the data is available for folks on the team – or your audience.
As a manager or leader on the team, it is always a good practice to remind folks that a trip report (unless specifically noted otherwise) is just anecdotal information and not a change in plans, a call to action, or anything beyond sharing. With the data from you and other sources, the right folks who are accountable should act. If you do have feedback then separate it from the report as a good practice.
About CES
Leading up to this year’s CES show, one might have thought the CE industry was in a lull and devoid of activity, let alone innovation, by reading a few of the pre-show reports. Nothing could be further from the truth. CES 2013 was another year of amazing things to see. More importantly, CES highlights the optimism that drives our industry. The pursuit of new products, new businesses, and most importantly combining those to come up with ways to simplify and improve life for people through electronics, hardware, and software.
It seemed to me that a good number of the early reports were a bit on the snarky side and reflected a view that there would not be any major disruptive or cool announcements. Folks were talking about a lull in innovation. I even read one blog post saying the industry was boring (I’ve met product people in most every industry and can honestly say they never think their own industry is boring).
Measuring innovation by what is new, shown, and/or announced for the first time at one of the world’s most massive tradeshows is not the right measure. Companies do not usually time their product development to coincide with tradeshows. Announcing a new product in a sea of thousands of other booths is not often the best communications strategy. In today’s world, announcements can be communicated broadly through a variety of channels and amplified socially at a time that fits the business.
Expecting a company to unveil something at the show is somewhat misplaced. On the other hand, a big part of CES, at least for me, is really being able to see any (large) company’s full product line “end to end” and to see how they are fitting pieces together to deliver on scenarios, value, or competition. Smaller companies have an opportunity to show off their products in a much more interactive fashion, often with very knowledgeable members of the team showing things off. Most importantly, CES lets you see “side by side” whole categories of products—you see the positioning, the details, and how companies present their products.
Unveiling a new product or technology that is a cross-industry effort, one involving many partners, does work particularly well at CES. Intel’s efforts around Ultrabooks, in 2012 and 2013, demonstrate this. While Intel’s booth and large scale presentations show off Windows 8 and Ultrabooks, the amplification that comes when seen on display at Sony, Samsung, LG, Toshiba, and more is where the sum of the whole is greater than the parts.
Many folks might not be aware, but along with the booths and all the semi-public displays, many companies conduct confidential briefings with press and partners at CES. These briefings might show off future products and strategies, but the reporters cannot write about what they see. In this case, CES is just convenient, especially for international press who don’t get to see US companies in person. It is an interesting approach because it can positively impact press coverage of already disclosed products when reporters know “phew, there’s more to come”. It could also frustrate, “hey I want to write about that”.
Writing a CES trip report is tricky for a non-reporter. Folks not there are following blogs and mainstream media and tens of thousands of stories are flowing out from LV. A tech blog might have 30-40 people on site and might file 300-400 stories from the floor—and that is just one outlet.
One person (me) can’t compete with that. But as a product development person, there’s a different lens—we’re looking at products and technologies as ingredients and competitors, not as things we’re looking to buy now. We are looking at trends and not necessarily the here and now. A way to think of it is that some go to CES as though it were a restaurant looking for a complete meal. Others go to CES the way that chef’s go to a market in search of ingredients for their ideal of a meal. The broad consumerization of CES sometimes leaves behind the notion that it is, in fact, an industry tradeshow.
CES 2013
CES 2013 was a fun show for me, spending about 15 hours on the show floor. I’ve always made sure in attending CES (or COMDEX or MWC or anything) to have time to see the show and experience the richness of the event. It is easy to lock yourself in a meeting room or go from private briefing to private briefing and convince yourself you saw CES, but CES is really on the floor. And the floor was buzzing. That’s also why this report is snark-free. There’s no such thing as an entirely objective report as every observer has a bias, but you can make a report free from snide remarks.
Trends
CES 2013 was definitely a year of refinement across many product lines. Pulling some themes across a broad set of products, there was refinement in many ways:
- Mobile. Stating the obvious, mobile is front and center for every product. Where CES used to think mobile was in the North Hall’s Auto section, now everything is mobile. Where cables, connectors, and wire used to occupy the LV Hilton (aka the Whyte House) there are now radios and antennas. Even power consumption is now focused on battery life rather than mains draw.
- Design language. The design language in use for both hardware and software is trending towards a clarity and minimalism–turning over the screen to the app and the customer. There’s a lot less glowing and translucency. Navigation is clearer. Touch gestures are assumed on any device and often are not readily apparent (that is designers are assuming you will figure out how to touch and tap to make stuff happen). And the use of the full screen for the task at hand is clearly dominant. Rather than gain “speed” or “power” via multitasking by arranging, widgets, picture in picture, and so on, the focus is on moving quickly between task-oriented screens. From program guides to elaborate settings on advanced A/V to apps for healthcare you can see this language. There is a new definition of productivity underway that’s sure to be the topic of a future post.
- Build quality. Across the board products are getting better. That’s not to say there’s a fair share of low-end and low-quality stuff, particularly tablets, one can see in the South Hall as usual. There is, however, a rising tide of quality. This is a sign of further upstream integration of components as well as maturing manufacturing and assembly. It is also a reflection of consumer demand—when the difference in quality is represented by a 10-15% price delta on a sub-400 dollar purchase, quality is generally worth it. That doesn’t change the desire for high quality and low prices, but physics still dominates.
- Service integration. It was hard to find a product that did not integrate with the web and back end service in some way. While third party services have been a theme for several years, the role of first party services is up significantly. These services are now a big part of the value of a hardware product. Telemetry is key service that is part of every product. While we might curse updates or think it encourages poor engineering, the reality is that the quality of what we experience is better than ever because of these updates.
- Social integration. The integration of products with social networks is technically an easy thing to do (these networks are motivated to have more updates flowing in) so it follows that many products now integrate with networks. You can hop on a scale and share the weight right away. You can share movies you have watched easily. You can even share how happy a meal made you.
- Broadening of Moore’s law. We all know how MIPS increased over time. We then learned how available storage increased over time. We’re now seeing this increase in bandwidth usage (UHD Netflix streaming, for example) and in the silicon based nature of visuals (screens and camera sensors, for example). Even wireless networking is seeing a significant uptick in speed. There’s a lesson in not betting against these changes—ride the wave.
- Connected life. For sure, the connection of our lives to the internet continues as a trend. It is really amazing how many analog things are being digitized—door locks, luggage tags, mouth guards, and more.
Downward trends
One of the neat things about going to the same show every year (I think this is easily 18 or 20 for me and CES) is to compare year on year what comes and goes. It is just an “observation” or “feeling” and not a measure of square footage or number of products. CES 2013 saw some interesting changes in products that were very present last year and less so this year.
Looking back at CES 2012 there were a few things that made an impression as a trend or were visible and went the other direction this year:
- 3D. 3D was really big last year and you really had to work hard to even find a booth with glasses at all. I can’t recall something that had so many real products you could buy (and could buy that previous holiday) and in one year essentially vanished. I’m still surprised by this a bit because the world is 3D—it seems that the technology approach wasn’t working so I would not write off the concept just yet.
- Storage. There was a lot less in the way of storage technologies—hard drive cages, USB drives and sticks, media storage cabinets even. The cloud world we live in along with seemingly unlimited storage in the devices we use indicate this trend will continue. Kingston’s 1TB memory stick was cool (though maybe a bit bigger than you might expect before seeing it).
- Waterproof. Last year it seemed like every booth had a fish tank holding a phone or tablet. While there were plenty of waterproof cases and a few waterproof devices, it might be that people go rafting with their tablets less than product folks thought :-)
- Media boxes. There used to be a seemingly endless array of boxes that distribute photos, videos, and music around a home network. With Pandora/Netflix/etc. built into every TV and DVD player (and apps on every device), this type of device has probably been integrated. For the enthusiast, the capability of using privately ripped media (and those codecs) around the house still requires a solution but that might be heading towards the homegrown/open source approach rather than product.
- Digital cameras and video cameras. The ubiquity of high quality cameras in our smartphones makes it tough for most of us to carry a second discrete camera. One thing to always look out for at CES is when one product category will be subsumed by another, but also be on the lookout for when people might be trying too hard on the integration/combination front. There was definitely a focus on making discrete cameras take on characteristics of phone cameras with user interface, Wi-Fi integration, and post-processing (sepia and toaster from your camera).
- Gesture based TV. The excitement of gesture based control of TV was all but gone. Last year every TV had 10’ of space in front of it so the demo folks could control it by gesture. The demos didn’t work very well and so this year TVs were being controlled by apps on tablets and phones. This might be subsumed by voice or might return with a much better implementation.
Impressionable products and technologies
While some products and technologies seemed to trend downward, there were quite a few exhibited that appear to be trending upward or remain at a very high level of interest and development. The areas for me that are worth looking into more as products are developed include some of the following (in no particular order).
UHD/4K. What’s not to like about 4K! The biggest crowds are always around the biggest screens and this year was no exception. Seeing the 100” and greater 4K screens is breathtaking. It is incredible to think that it was just two years ago we were ogling at a 60” LED 1080P screens. Moore’s law applies to screens. Every major TV/screen company was showing 4K screens and these will be products soon enough for sure, and then the prices will come down. Folks were debating the value of 4K on different screen sizes or in different room sizes. Even though the physics can prove your eye can’t resolve the different, the physics of manufacturing screens will make it cost effective to use high density pixels counts almost everywhere. Obviously as we have seen with devices, there’s work for software (content) to just work at 4K—each company was showing native 4K and upscaled HD content to show off their technology for future and present content. Can has?
Display technology. The technology behind UHD displays is also on the move. This year saw a significant amount of credible innovation in the area of screen technology. Flexible displays seem more realistic than past years because they were in more than one booth. OLED made a strong reappearance with an amazing 4K OLED screen. Curved screens that match what we see in movie theaters showed up. I loved the wide aspect ratio screen from LG. Touch is being integrated into large panels for use for broadcast, meeting rooms and signage. Even the distribution of HDMI signals for digital signage saw innovation with single CAT5 systems at commodity prices. Samsung had a very cool transparent display that allows a physical product to be “enclosed” in the screen.
Multi-screen. There’s an incredible desire for the ability to get what I am seeing on a phone or tablet on to a bigger screen (the flipside of getting what streams over cable/sat onto my phone/tablet is a different problem). To really solve this well (respecting digital rights, getting everything on the screen) should be a low level connection like “wireless HDMI” but the power, bit rate, and complexity of that has not lent itself to a solution (below is a photo of HDMI test equipment if you ever wanted an idea of the complexity of the signal, or just cut an HDMI cable and look inside). Software solutions turn out to have equal complexity when you consider the decoding required in a TV (where component pricing is critical). DLNA holds out hope but is suited to photos/videos. AirPlay has the presence of iOS devices but needs Apple TV connected over wires. Sony, LG, Samsung, and others are starting to show solutions based on Miracast. This has some real potential if screens and projectors start building this in (and today you can get the aux box via third parties such as netgear). The other part of multi-screen is the aux screen scenario–the tablet screen show auxiliary content or is a remote control. There was somewhat less of this in 2013 compared to last year. This seems to be struggling with scenarios and responsiveness right now but seems like it will be figured out—after all, how many of us watch a movie and look things up on IMDB on our phones or watch sports tracking another game or stats on our tablet? The scenarios last year were focused on Facebook/twitter on your TV or news/weather while you watch and that is what seems to have been reduced in excitement (those always seemed a bit awkward to me for a family room).
Cameras. The first consumer digital cameras were shown at CES back in the early 90’s. It was so interesting because prior to that cameras had their own show. Fast forward 20+ years and cameras are 100% electronics. While discrete consumer cameras are struggling a bit to find a place in a world of phones, digital SLRs are seeing a rebirth at a level of flexibility and sophistication that is mind blowing. The role of DSLR for video has spawned a whole industry of accessories to morph a still camera into a motion camera in terms of form factor (the sensor and lens are the real value). Image stabilization, critically important on tiny form factors, is becoming incredibly good. Tablet sized devices are becoming reasonable for cameras (last year I thought it looked really goofy and this year it seems to make sense). One has to think though that there is a digitalization of “lenses” yet to happen. The physics of optics is due for a rebirth – the improvement curve on lenses and the SLR model seems to have reached the limits of physics. The new Canon 200-400 f4 with integrated 1.4x converter lens is super cool, but so heavy and costly. The next generation of cameras that go beyond using silicon to duplicate the resolution of film will break through at a future CES. Often you see products go through the “use electronics imitate the analog world” for a while before they find their digitally authentic expression.
The following is a 10 second video showing image stabilization from Sony. The image is a live image from two cameras mounted on a shaking platform, above the large screens.
Phablet. The made up word that was used more than it seems like it should was Phablet—a device that is bigger than a phone and smaller than a tablet. Given the size of phones this might mean 5-6.9” or so. It seems that there are two views. There’s the view that a phone is a phone and should be “less than” some size, and a tablet is a tablet which is 7-8” unless it is a big tablet (9.7”) or a PC/tablet. The other view is that consumers will be selecting from a wide variety of sizes and the industry will meet many needs. I like this second view. While I might choose a more routine phone size, too many people like larger sizes. Whether a larger screen is the one device someone uses or no is a tricky question. More than size, the pixel density is something to consider because apps won’t scale arbitrarily and how to scale at certain combinations of diagonal size and ppi have real impact on the quality of interaction with apps. I would not discount the consumer demand for a sustainable market of a variety of sizes of portable devices.
DISH/Directv/Comcast. The companies that distribute “real TV” to consumers (especially live events and original programming) seemed especially innovative this year. DISH is particularly innovative in bringing together a very nice and high quality multi-room and multi-device scenario. One thing that really struck me was the new ability to flag a program for transcoding to your mobile device and easily download it. To date this has been mostly impossible to do. Unless you want to wait for DVD or streaming this is the only way to time and location shift first-run programming. Programming guides are getting much better and faster to interact with and the integration of fun data (related programs, background info) is great to see. Getting to place where you have one tuner box and then much smaller, fanless, storageless, settop boxes in other rooms is really close.
Health. CES hosted a separate exhibit area for health related products/services (this is where they are encouraged for being part of the themed area). These products are truly modern products—empowering consumers with technology to literally improve their lives, and connect them to the internet and other resources. There are all sorts of sensors for well-known human telemetry: weight, blood pressure, pulse oximetry, glucose level, air quality, distance traveled, and more. There are also sensors for fuzzier (computed not measured) areas such as concentration, sleep quality, mood, and so on. The common element for all of these is measurement with a device that connects to the internet (or directly your mobile device via bluetooth) and then on your device you can view trends, track, and analyze the data. For many people this is literally life and death (tracking bp, glucose). For many it is a way to maintain fitness levels or achieve a better level of fitness. Two things really struck me. First, there is a real responsibility these companies will need to shoulder to separate medically actionable data from telemetry that will simply drive you crazy and drive up medical costs for society (tracking pulseox for a normal healthy person is dubious). Second, these are really a unique set of products/services/businesses that are essentially mobile-only, profiting by either the device sale or a device + service subscription. Some are not even bothering with web-browser based viewing.
New PCs. While Dell, HP, and Microsoft were not showing their own booths, there were plenty of new PCs. This was newsworthy and clearly showed a focus on “designed for Windows 8” which is exciting. Intel pulled together many of these PCs under the Ultrabook moniker and announced specs for the next generation of Ultrabook logo PCs (including touch). Samsung, LG, Toshiba, Sony, Panasonic, Lenovo all had very nice PCs with hiqh-quality touch, nice trackpads, great screens, thin, light, and in a variety of screen sizes 11-15. The All-In-One PCs with touch were quite nice as well, especially Sony and Samsung’s models. The Vizio lineup continues to evolve and show unique designs and good value. Razer was showing a Core i7 based tablet designed from gaming with some awesome gaming attachments. Panasonic shows a 20” 4K tablet that blew me away—seeing the quality of AutoCAD drawings showed a real value to the full “stack” of hardware and software. There were a number of hybrid PCs (tablet with removeable/hideable/flippable keyboards) that are becoming clearer and more refined—I especially liked the Samsung and Lenovo entries. These PCs are really great for developers and designers—they let you work directly with the code and a client/designer at the same time in both coding and tablet usage styles. As with “phablet”, it seems that the variety of tablets enabled by Windows will be something that continues to bring innovative ideas to consumers.
Green. There continues to be a push to make sure devices are green—while that lacks a concrete definition most devices are touted as low(er) power than they used to be. With the focus on mobile most devices are already much lower power than a tower PC of 2 or 3 years ago and even the 27” all-in-ones are running low-power chipsets and using aggressive OS power profiles. There are numerous power strips that reduce draw and drive “standby” behavior through certain outlets. There were a number of power strips that said they were greener because there was one integrated DC converter for charging USB devices. I loved the case/bag companies using recycled materials to make bags (though it still isn’t clear if this is carbon neutral or not, but for sure the developing world figured this form of reuse long ago making carry bags out of rice and grain bags). The most interesting challenge is that to really reduce power consumption (and extend battery life) requires hardware and software working together. Hardware companies announce the power draw of the hardware independent of the software platform; devices advertise battery life independent of radio signal strength or app load; manufacturers can create a software profile (drivers and more) that is not optimal for the advertised hardware number. There’s a lot to get this right.
Wireless communications. Obviously wireless mobile communications are everywhere, literally. One product due for a revolution in this regard is LifeAlert (“help I’ve fallen and I can’t get up”). Lifecomm is a Verizon product that houses a full 4G “phone” in a bracelet or dongle. Push a button and your location and information generates an assistance call right to you and a dialog can also take place—no matter where you are in Verizon’s service area. Super cool. Greatcall has a similar product that is a keychain form factor. There were related products for pets and luggage as well, but the one for humans seems to be particularly valuable.
Neat new companies
Everyone who goes to CES always tells you that the smaller companies have the coolest innovations. It takes a lot of energy and some luck to really find one of these. Even if you’re the press and get all the requests to meet you still have to pick from a thousand choices. I happened to stumble across a couple I thought I’d mention.
Qubeey. This is a startup from the Los Angeles area. That already makes them different as they are not a “tech” company, but a company that uses tech. They think a lot about how to connect entertainment to the audience that cares about them. If you’re a self-expressed fan/follower/friend of a talent then Qubeey provides a way for that person/band/brand to “push” highly interactive content to you that overlay the context of what you’re doing on your mobile device/win/mac. They have cool overlay video technology and even interactive SMS games. It is a unique approach to what amounts to advertising but doesn’t seem like that because you signed up to interact with something you care about.
“Secret”. I had a chance to see a briefing for a top secret gesture based technology that is very nice. This is a technology out of university labs about to be a product for TV/device makers. It uses a single off the shelf camera (like in an iPhone) and then uses CPU/GPU to compute the tracking of your hands for gesture based UI. This is cheaper, smaller, and less complex than other solutions out there. I saw it in action and it works remarkably well—there’s almost no latency between hand movements and tracking. It works at the driver level so it can use gesture to emulate touch with existing games and software. It can be easily trained to track an object as well (like a wand, sword or saber) for games.
Tablet cases. There were a lot of cases for tablets. Seriously there were a lot of cases for tablets from companies big and small, new and old! It is clear that tablets have a need for more protection, keyboards, and stands. I tried to capture photos of some of the variety of cases/add-ons that add style, keyboards, and protection, but also add significant size and weight to what are otherwise sleek and light tablets. Many seem to hinder the ergonomics of the device, unfortunately. I really don’t understand why someone hasn’t built a tablet yet that has a really strong case, built in stand, and a cover that also allows typing. I said free of snark, not free of sarcasm :-)
More observations
Here is a great example of the work Panasonic consistently does for universal access. Their voice control TV won an innovation award for universal design.
IEEE was running a poll to determine views on what gadgets are no longer in use (“Gadget Graveyard”). I love the irony–a gadget graveyard from the engineers that brought you the gadgets.
Phew. Another CES. Every year the new products energize me and show just how much creativity is going on in our industry.
–Steven
PS: Please see the Disclosure page that has been added. The link is on the right rail.
###
Engineering and social science lead to plans
One of the biggest challenges of building technology products is that to bring a technology product or service to market requires great engineers to do their best work without really knowing the answer as to whether the choices being made will yield success or failure. This seems obvious but is often the greatest source of tension in a product team and just about every juncture.
Note: When saying “engineer”, please take it to mean all of the specialized skills involved in building a product inclusive of development, testing, design, operations, and more, and when saying “sales” or “marketing” take that to mean all of the specialized skills involved in getting a product into the hands of customers and supporting it—there is a spectrum of skills and responsibilities, which is critically important. No matter how many or how few specializations, the seams between roles are always fuzzy and that is good.
Natural tension [sic]
Any non-engineer who has ever interacted with an engineer knows the challenge (or frustration) of being told something can or can’t happen, or that something is right or brain-dead, or worse the stupidest idea ever. Likewise, every engineer knows the frustration of dealing with a salesperson, marketer, or customer who insists on something being done a certain way but can’t offer any rational explanation. This is often referred to as a natural tension or instituted balance of power on a team.
But who wants an instituted tension? There’s enough stress in just doing what needs to be done from your own perspective without the need to institutionalize more with no hope of resolving it.
The challenge is not easily overcome. Sure you can have engineers visit customers or you can have sales folks sit in on an architecture review, but these are anecdotal and don’t really infuse the relative challenges and contexts each party faces. In fact there is no easy answer because the reality goes back to the training, culture, and even time horizons of the different members of a product team. Rather than assume a natural tension, rely on anecdotes, or attempt to converge the DNA of the team there might be a better approach.
If you think about a team as a set of folks each coming to work to make difficult choices each and every day (and night!) then the critical element for the team is a shared and detailed sense of the overall plan for a product. Historically software planning has not matured to the degree of planning for most other engineering endeavors (construction, transportation). For the most part this is viewed as a positive—it is the “soft” part of software that makes it fun, agile, and in tune with the moment. Likewise, in the world of blogs and social media, the ability to re-craft the message to customers about a product can change much more rapidly than the days of lead times and print advertising. Again this is also a positive.
But if each perspective on a team is maximizing their creativity and agility, it doesn’t take long for chaos to take over. And worse, if things get chaotic and don’t come together well then fingers start pointing. Throw in a bit of performance evaluation or an executive meeting and what was a small disagreement becomes a wedge or worse, “politics”, very quickly. It is often amazing how quickly the most well-intentioned folks working together can start to have that so-called natural tension turn into a genuine dysfunction.
A plan for what is being built can sound so heavy or burdensome. It can be. It doesn’t have to be. Another word for a plan is a “framework for making decisions”. It is easy to make a plan that says all the amazing things that will be done and all the amazing ways money will be made. That’s the easy part.
Another easy part is listing all the things that won’t be done–sort of so everyone is clear on the inverse of what is being built. This sounds weird. I remember the first time I learned of a technique of deliberately detailing the non-goals or cut features of a project. I found this a puzzling disclosure–and maybe it was a specific device in a limited set of teams. If you list the project goals, then isn’t anything else that can be talked about a non-goal? The same goes for detailing features or outreach plans by priority. A lot of times you see lists of features/goals with priorities but that leaves it unclear which ones will get done (all the musts and a few maybes, most of the musts, etc.) – it seems best to simply list the ones that you’re signed up to do since for the most part I don’t think any of us have worked on a project where there was a surplus of time or money!
The hard part about making a plan is establishing the context of why a product is being built and how it will be successful. This is the social science aspect that is tough on an engineer. You can’t prove something will be a success in the market since there are no equations that govern market behavior. Similarly, the role of the technologist is to draw a trajectory of technologies to a world that might be different from the here and now, the here and now where people are spending money today. This is the social science that is tough on the sales and marketing team members.
What’s in a plan
For a project of any size that goes beyond a handful of people or involves any complexity, detailing the how and why of a product, not just the what, is a critical first step. The reality is that every member of the team benefits from the context and motivation for the project. Armed with that information there is a basis upon which to make decisions—decisions about how to implement features, decisions over priorities of features, decisions about how the product will be positioned or sold, and so on. It is amazing how often you run into engineers that know precisely what “needs” to be done but there isn’t really a good story as to why, or conversely how often you can find the marketing folks knowing what story would sell well but don’t know how to create that story. The point of a plan is to build a bridge made up of the how and why, not the what.
Of course things change. Code is harder to write than you would like. Competitors fill a void. Customer views change. In fact any project is going to go through a phase of questioning parts and resetting details of the plan. The most counter-intuitive notion of a plan is that the presence of a plan means you have the tools to change the plan, together as a team. The absence of a plan is what creates the chaos, finger-pointing, and accountability dodging that we’re all familiar with. A plan does not imply rigidity, but like any tool a plan can be abused. There are people who think plans are chiseled into stones. There are also people who think a plan is just a starting point and that everything is dynamic. Product development is a dynamic system with plans provided the needed anchor points for the team as a whole, across disciplines.
Some things you might take into consideration when working to create a plan might include:
- Current product state. If you’re updating an existing product, then there should be a shared understanding of how the current product is being received in the market. What are the strengths and weaknesses technically and in terms of the business? Those responsible for selling and supporting the current product should lead the creation of this content.
- Business opportunities. Where are customers spending money? Where would they be willing to spend money? For competitive products, how are these products sold? In most teams there are people who deeply understand the revenue model and cost structure of a product and those folks should lead the creation of this part of the plan.
- Competition. Everyone should understand the competition. This is not the sort of thing that should be done casually, but everyone on the team should know the competition inside and out and use competitive products and services full time. A lot of damage gets done to plans when people casually try out a competitor and don’t make the mind shift required to understand why customers might be migrating to competitive products. And keep in mind that competition might be disruptive and offer a product with “less” functionality but with a different model for making money. Driving this part of the plan requires teamwork.
- Partnerships. Every technology product is made up of partnerships. Building a platform, an app, hardware or software requires partnerships with developers, hardware makers, component makers/supply chain, post-sales deployment / support (for enterprise products), and more. Even something as basic as a plug-in model or extensibility API needs to be thought through if you want it to be part of the decision framework for the team. Again, this part of the plan requires the team’s perspective.
- Industry trends. The social science of putting a plan together really kicks in when the team starts to consider what the technology trends look like. What’s the timeframe? What’s the likelihood of a trend panning out? What is the upside / downside to the project if a given trend pans out or not? These are important questions. But agreeing up front on the waves a product is riding and being detailed enough that everyone is clear is important. This is where the nuance of a plan really comes into play. Today every plan might say “mobile” but the question is much deeper than that when it comes to how to act—how does that relate to monetization, what platforms, and the relationship to the browser are all critical “trends” to articulate.
- Define success. What does success look like? As part of planning, sometimes a tool that is helpful is to pull together all the above and write the announcement blog post (aka press release). Is that credible? How would competitors respond? Engineers should consider defining success in terms of simultaneous users, transactions, or performance in addition to the features. Everyone works together to define success.
- Timeline. Every good project starts with a timeline. And most projects quickly revise that. The real challenge with any planning effort is to pick a timeline that you genuinely believe in up front as a team and then use the above efforts to make tradeoffs to stick to the timeline. If you’ve scoped the work to the timeline and set an achievable timeline then changing the plan to account for unknowns is how you keep everything real. Because developing a plan is iterative, the timeline is informed by the plan–you don’t take the plan then go decide what can get down (or how long it will take), like the old waterfall model.
When you look at this framework three things might jump out.
First, the plan is not a top line business goal “get n% of Y” where Y can be customers, dollars, or some share measure. It is also not “get these 5 features done”. Those are potential measures of success but not the headline of a plan. The headline of a plan is a solution to a problem—whether customers expressed pain (an articulated need) or the team is anticipating a solution (unarticulated need).
Second, the plan is a team effort. Even developing the plan takes a coordinated effort across the team. One way to talk about this is that a plan is not any one of “top down” (executive handed on down) or “bottom up” (crowd sourced), using the classic description of top, middle, bottom. Rather planning is a process that requires a coordination of top down, bottom up, and middles-out. The best plans are the plans that have the best ideas from the broadest set of folks contributing to building the product.
Third, one might be tempted to look at this as a PowerPoint outline and do a slide on each one. A lot of plans get made that way :-) The only approach to planning is to write down the plans in words, Word, and to go through a process of making sure there is a consistent voice to the plan. That process of writing down the plan is just as important as the ideas within the plan. Perhaps the topic for a future post.
Building a bridge
As the team comes together with a shared understanding of topics such as those above, the next step is one that can be taken together. There are two key parts of the plan that really bring together the context and help to bridge the “engineering plan” and the “social science instinct”.
- Big Bet(s). Every project is made up of one or two significant bets. These can be new technologies, break from the past, or new product area. These are the parts of a product that go beyond the incremental improvement (relative to your own previous release or to competitive products viewed in the same space). Detailing these up front is a really helpful tool because it means that there aren’t any other big bets. Big bets are generally the immutable parts of a plan–the plan doesn’t really hold together without the bet and it isn’t likely that part-way through a project you could add another big bet. So big bets serve as a foundation upon which future choices and decisions about a project can be made. It is tempting to have a lot of big bets, but even the largest projects cannot really sustain more than a couple–remember once the team commits to a big bet the idea is that it needs to get done no matter what or said another way, the soul of the product rests on getting this part “right”.
- Engineering plan. The engineering plan can be thought of as a feature plan but is better thought of as a scenario plan when viewed through the eyes of engineering. When viewed through the eyes of the sales and marketing members of the team, an engineering plan should read like a “we solved these problems” which can relatively easily get translated into the “story” of the product/service or the “positioning”. It is a good idea for the engineering plan to be separate from the organization chart and to really represent the cross-team efforts (if that is applicable). Even the most straightforward app these days is a front-end/app/UI and a back-end/service and those are often teams (or people). Making sure the product goals are expressed as what those do together, not what they do independent of each other, will also help to bridge the engineering plan and ultimately the business and marketing strategy.
There are many more parts to a plan–the business plan itself, the marketing plan, the PR plan, the pricing structure, the materials to train support and sales people, the operations / scale out plan, the test plans, the self-host plans, and so many more. The above represents some tools that the whole team can potentially benefit from if the work is done before the project really starts. As teams get into rhythms more things can be done up front and together. This is just a framework for when the first goal is getting folks on the same page to build something.
As much as we’d like, there is no magic answer or formula. If there was, then all projects would use it and would just be well-executed. No product is developed twice, so our collective ability to experiment and to design/iterate on a specific instance of product development is limited. All we each have is experience and paying close attention to the context and here and now when developing a product.
–Steven
PS: Thank you for reading. This was a first post in this blog–a learning process. I welcome feedback on the tone, structure, and approach. These are complex topics and I’ll probably see the shades of grey or middle ground more than the “answer”. Let me know what you think.
PPS: This post is about the general topic discussed and is not about anything specific in the past or present.
###
Welcome to “Learning by Shipping”
Welcome to the Learning by Shipping blog—thoughts and perspectives on product development, management, and the process of bringing new products to market.
This blog is a continuation of writing on these topics through several different blogs, some internet and some intranet. For me, blogging started in the summer of 2005 with Techtalk, a blog focused on the college hiring process at Microsoft. When I changed jobs and moved to Windows, there were many questions inside Microsoft about how we would do things (in what was often referred to as a post-Vista recovery), but not just with Windows but with Windows Services (called Windows Live back then), Internet Explorer, and even Search (not yet Bing) which was part of our team for a while. The size of the team and the pace we needed to change required a different approach to communication. The Office Hours intranet blog was started in an effort modernize the communication channels.
Office Hours was a blog that discussed the challenges and choices in creating and managing large scale products and services. It was a candid view of what was going on in real-time and was read by many across teams inside of Microsoft. There were hundreds of posts (roughly weekly), some of which can be found in various places on the internet, unintentionally, and some of which can be found, intentionally, in a book co-authored with Marco Iansiti at Harvard Business School. The posts tried to take on the topics of building complex products used by many types of customers, by a team made up of diverse skills, in a company made up of a lot of people and a lot of other products.
Along the way, there were several product-focused blogs that influenced this style and approach. We wrote about Office 2007 through a number of folks on the team. With Windows 7 and Windows 8 the team and I blogged quite a bit, and often at great length :-), about the design choices, implementation, and features of those products.
Learning by Shipping picks up where these blogs leave off. The title comes from something impressed upon me early in my career, which is that learning as an engineer comes from the process of starting, then finishing, and iterating on products–getting products to market and putting the broad feedback loop to work. The teams and processes used to create products are critically important and fun to talk about relative to shipping and learning as we search for the best approaches to use at a given time.
The most fascinating aspect, for me, of technology product development is the intersection of engineering and social science. As engineers we are trained to find the right solution(s) given a set of constraints. Product development is about the inherent uncertainty of business and customer needs and desires, and those change depending on the context. There are no right answers, only varying success in the marketplace at a given time. The pendulum of ideas swings back and forth depending on the context–the availability of underlying technologies, the acceptance of different business models, or the solutions most valued by potential customers. The same holds for approaches used by organizations building products–the right answer depends on the context and can change over time. These choices and the pros and cons of different approaches are interesting topics that occupy many of us as we search for the right path for our development efforts.
The focus on this blog won’t be about specifics or the past regarding Microsoft, of course. Some topics might come from current events as the basis of more general posts. In previous blogs, most all of the topics came about through interactions across the team. In this new blog, I am hopeful that there can be a rich dialog about the “how” and “why” of building products in our industry and that serves as springboard for posts.
I’m not sure yet how often I will post–this is a bit of an experiment. I will work to keep posts free of snark and ad hoc criticisms in hopes that the comments and back and forth will be the same. Comments are not moderated and only the hosting site’s spam filtering is in use. As a reminder, I will make mistakes in this blog in both form (typos) and substance (facts) and will take responsibility for those when called out.
I’m super excited to see how this experiment goes.
Please feel free to subscribe to the feed on the sidebar or follow on twitter for alerts on posts.
Steven Sinofsky
steven@learningbyshipping.com, @stevesi
###
Learning by Shipping 