Posts Tagged ‘strategy’
Using data to inform strategy
Access to rich usage data is something that is a defining element of modern product development. From cars, to services, to communications the presence of data showing how, why, when products are used is informing how products are built and evolve. To those developing products, data is an essential ingredient to the process. But sometimes, choices made that are informed by data cause a bit of an uproar when there isn’t uniform agreement.
The front page of the Financial Times juxtaposed two data-driven stories that show just how tricky the role of data can be. For Veronica Mars fans (myself included), this past week was an incredible success as a Kickstarter project raised millions to fund a full length movie. Talk about data speaking loud and clear.
This same week Google announced the end of life of Google Reader, and as you can see from the headline there was some controversy (it is noted with irony that the headline points out that the twitterspehere is in a meltdown). For all the 50,000 or more folks happy with the VM movie, it seems at least that many were unhappy about Google reader
Controversy
The role of data in product development is not without controversy. In today’s world with abundant information from product development teams and analysis of that data, there is ample room to debate and dissect choices. A few common arguments around the use of data include:
- Representation. No data can represent all people using (or who will use) a product. So who was represented in the data?
- Forward or backward looking. When looking at product usage, the data looks at how the product was used but not how it will be used down the road (assuming changes). Is the data justifying the choice or informing the choice?
- Contextual. The data depends on context in which it is collected, so if the user interface is sub-optimal or drives a certain pattern the data does not necessarily represent a valid conclusion. Did the data consider that the collection was itself flawed?
- Counter-intuitive. The data is viewed as counter-intuitive and does not follow the conventional wisdom, so something must be wrong. How could the data overlook what is obvious?
- Causation or correlation. With data you can see an end state, but it is not always clear what caused the end-state. If something is used a lot, crashes a lot, or is avoided there might be many reasons, most not readily apparent or at least open to debate, that cause that end-state. Is the end-state coincident with the some variables or do those variables cause the end-state?
When a product makes a seemingly unpopular change, such as Google did with reader, some of more of these or other arguments are brought forward in the discussion of the choice.
In the case of Reader, the official blog stated “usage of Google Reader has declined”. While it does seem obvious that data informed the choice, if one does not agree with the choice there is ample opportunity to dispute the conclusion. Was the usage in absolute or relative decline? Were specific (presumably anonymous) users slowing their usage? What about the usage in a particular customer segment? The counter-intuitive aspect of the data showed, as most dialog pointed out strong first party usage among tech enthusiasts and reporters.
The candid disclosure of the use of data offered some transparency to the choice, but not complete transparency. Could more data be provided? Would that change how the product development choice was received?
Conversely, no one is disputing the success of the VM Kickstarter project (making a movie is similar to product development). The data is clear, there is a high level of demand for the movie. I know that fits my intuition as a fan of the series. The fact that this data came via a popular (and transparent) web service only seems to validate our intuition. In this case, the data is seemingly solid.
While these are just two examples, they happened in the same week and show the challenges of data, transparency, and product development choices. While data can inform choices, no one is saying it is the only way to make a choice or that those making products should only defer to data. Product development is a complex mix of science and intuition. Data represents part of that mix, but not the whole of it.
Data is not strategy
Ultimately, data contributes to product development but does not replace the very unscientific notion of what to build and why. That’s the art of product development and how it intersects with business strategy. This follows from the fact that products are developed today for use in the future. The future is uncertain for your own product’s evolution, but all around you is uncertainty. Data is an input to help you define a strategy or modify it, but cannot replace what is inherently the uncertain side of innovation.
In Eric Ries’ Lean Startup book (or http://en.wikipedia.org/wiki/Lean_Startup), there is an interesting discussion on how the role of data can contribute to an early stage product. While the anecdote and approach are described in the context of a project very close to Eric, I think we can all see parallels to other products as well. My intent is not to restate or recast the book, but to just reflect upon it a bit.
One part of developing a new product, as described, is to develop a minimum viable product (MVP) that does not reflect the final product but is just enough of the product to collect the maximum validated data about potential customers.
An interesting point in the description is how often the people that will use this early version of the product are enthusiasts or those especially motivated and forgiving about a product while under development. The tricky user interface, complex sign-up, or missing error conditions and things like that might not matter to these folks, for example.
Not every product ultimately targets those customers—they are not super large in number relative to the broad consumer world, for example. As you learn and collect validated data about your product strategy you will reach a critical point where you essentially abandon or turn away from the focus on enthusiasts and tilt towards a potentially larger customer base.
This is where your strategy comes into play. You have iterated and validated. Presumably these early users of your product have started to use or like what you have or at least pointed you in a direction. Then you’ll take a significant turn or change—maybe the business model will change, maybe there will be different features, maybe the user interface will be different. This is all part of taking the learning and turning it into a product and business. The data informed these choices, but you did not just follow it blindly. Your product will reflect but not implement your MVP, usually.
But with these choices there will probably not be universal agreement, because even with the best validated data there can be different approaches to implementing the learning.
Data transparency
The use of data is critical to modern product development. Every product of every kind should have mechanisms in place to learn from how the product is used in the real world (note, this is assuming very appropriate policies regarding the collection and usage of this data). This is not just about initial development, but evolution and maturing of the product as well.
If you’re going to use data to design and develop your product, and also talk about how the product was designed and developed, it is worth considering how you bring transparency to the process. Too often, both within an organization and outside, data is used conveniently to support or make a point. Why not consider how you could provide some level of detail that could reduce the obvious ways those that disagree with your approach might better understand things, especially for those that follow along and care deeply. Some ideas:
- Provide absolute numbers for the size of the data set to avoid discussions about sample size.
- Provide a sense of statistical significance across customer types (was the data collected in one country, one type of device, etc.).
- Provide the opportunity for additional follow up discussion or other queries based on dialog.
- Overlay the strategic or social science choices you are making in addition to the data that informed the choices.
Transparency might not remove controversies but might be a useful tool to have an open dialog with those that share your passion for the product.
Using data as part of product development will never be free of debate or even controversy. Products today are used across millions of people worldwide in millions of different ways, yet are often used through one software experience. What works in one context doesn’t always work in another. What works for one type of customer does not always work for another. Yet those that make products need to ship and need to get products to market.
As soft as software is, it is also enormously complex. The design, creation, and maintenance preclude at today’s state of the art an everything for everyone approach. To make those choices a combination of data an intuition make a good approach to the social science of product development.
–Steven
PS: Please click the link on the first use of data for a discussion of data versus datum. :-)
Rightsizing your product plan, but not your vision
Creating a product, whether totally new or an update, means deciding what’s in and what’s out. The main execution constraint you have is the time you are willing to spend developing your product (or the number of developers, roughly the same thing). In your planning you need to decide the right amount of work to do to create, or justify, the product—rightsizing your product plan. Executing a rightsized plan without compromising your vision is a core product development skill.
What is rightsizing?
While most all product development debates take place at a fairly granular level—having a specific feature, architecting an investment, choosing how to communicate the work—there are some broad topics that can have a profound impact on how the product evolves. The most critical first step of a project is to decide the “scope”. Deciding the scope of a project is an active conversation across all the stakeholders involved.
For software and service projects (note, project=product=service) the scope determines a whole host of choices, and even how you articulate the scope can open up or foreclose options. You sort of need to start by checking in with the realities of your foundation:
Entirely new product. An entirely new product is the opportunity to scope a product to a minimal set of features or needs. In other words you can literally pick the smallest set of features/investments to express your scenario or goals. It has become common to refer to this as a minimum viable product or MVP. Another aspect of “new” is whether the project is new to your company/organization or new to the industry as a whole. There’s a tendency to view scoping differently if something is entirely new to the world versus new to your organization. An MVP can take on one meaning for a startup where there are no expectations for “minimal”. For an existing company, this becomes increasingly challenging—things like globalization, accessibility, security, integration with existing account infrastructure, and more can set a significantly higher bar for “minimal”.
Evolving an existing product. Most all software is about evolving an existing product. In scoping the work to improve an existing product the main dimensions that determine the scope will be compatibility with the current product—in user experience (keystroke, flow), data (file formats, previously saved work or settings), features (what a product does), or platform (APIs, add-ins). In scoping a product plan for an existing product, deciding up front to maintain 100% of everything itself has a cost, which to the outside world or management, might be counter-intuitive. Regression testing, design constraints, and even what you choose to do differently with existing features determine the scope of the new work for the release. Sometimes a product can be new for the company even if it evolves an existing product, but these same constraints might apply from a competitive perspective.
Disrupting an existing product. Any project can evolve for some period of time and eventually requires a significant overhaul—scenarios change, scale limits reached, user experience ages, and so on. A project that begins knowing you will disrupt an existing product poses a different set of scoping challenges. First and foremost you need to be clear on what part of the project you are disrupting. For example, are you considering a full re-implementation of an existing product or are you re-architecting a portion of an existing product (again, say the UI, API, or features)? Sometimes a product can be new to your organization but disrupt a competitive product, which brings with it a potentially different view of constraints.
Side-by-side product. One type of project scoping is to decide up front that your project will coexist with a product that solves a similar problem from your customers/company/organization. This approach is quite typical for internal IT systems where a new system is brought up and run in parallel with the old system during a switchover period. For a consumer product, side-by-side can be a shorthand for “keep doing it the way you’re doing it but try out our system” and that can apply to a specific set of customers you are targeting early in development.
Each of these is more granular and real-world in an attempt to cover more of the software projects so many of us work on. Typically we look at projects as “new product” or “update” but tends to over-simplify the project’s scope.
Many projects get off to a rocky start if the team is not clear on this one question of scope. Scoping a product is an engineering choice, not simply a way to position the product as it is introduced. For example, you might develop the product as an evolution of a current product but fail to get some of the baseline work done. Attempting to position the product as “totally new” or “just run it side by side” will probably backfire as many of the choices in the code do not reflect that notion–the seams will be readily apparent to customers (and reviewers). As with many challenges in product development, one can look back at the history of projects, both successful and not, and see some patterns to common challenges.
Pitfalls in scoping
Deciding and agreeing up front to the scope of your product is a critical first step. It is also easy to see how contentious this can be and can often generate the visceral and stereotypical reactions from different parts of a collective team.
If you develop an enterprise product and propose something that breaks compatibility you can expect the scoping efforts to be met with an immediate “requirement” that compatibility be added back to the plan from your enterprise sales force, for example.
A consumer product in a space such as note taking or writing, as an example, can certainly be immediately overloaded with the basics of text processing and image handling. Or one can expect reviewers to immediately compare it to the current most popular and mature product. We’re all familiar with the first release of products that received critical reviews for missing some “must have core features” (like copy/paste) even though they had a broadly disruptive first release.
The needs for a product to be global, accessible, or to plug into existing authentication mechanisms are examples that take a great deal of up front work to consider and clarify with the team (and management).
In fact the first pitfall of most scoping efforts might be the idea that disagreements up front, or just different points of view that have been “shelved”, will be easily resolved later on. One coping mechanism is for folks to think that the brilliance of the product’s innovation will be apparent to all parties and thus all the things “out of scope” will go from a disagreement to shared understanding once people see the product. My experience is that this isn’t always how it works out :-)
The most difficult challenge when you’re scoping the project is that you actually considered all of these “obvious” things, yet as people see the product (or plans) for the first time these come across to them like obvious misses or oversights. You probably know that you could add features that exist in the marketplace, that you’re breaking compatibility, that you’re going to need to run side-by-side, that you’re not ready for complex character sets, and so on. Yet as the product is revealed to peers, management, reviewers, or even as the team sees the whole thing coming together there’s always a chance of a bit of panic will set in. If you’ve gone through an effort to plan the scope, then none of this will be news and you will have also prepared yourself to continue forward progress and the discussion for how and why choices were made.
Even with that preparation, there are a few common pitfalls to project rightsizing that one needs to consider as a project goes from planning through execution. These pitfalls can surface as the product comes together and the first customers see it or these can be the reason the product isn’t getting to a stage where others can see it:
- Backing into a different scope. The most critical failure of any project is to think you can revisit the scope of the project in the middle, and still stay on time. If you decide to break compatibility with the existing product and build out new features assuming this approach then you’re faced with rearchitecting the new features, cutting them, or some decidedly tricky middle ground. Taking a step back, what you’re really doing is revisiting the very approach of the whole product. While this is possible, it is not possible to do so on the schedule and with the resources you have.
- Too much. Most all of us have scoped a project to do more than we can get done in the time and with the resources we have. A robust product plan provides a great deal of flexibility to solve this if you were clear on the scope—in other words a feature list that is too long is easy to trim. This is decidedly different than trying to change scope (change from disrupting the product to evolving the product for example). If all you have is too many features, but the intent of the release is consistent with that long list—I promise there are features to cut.
- Too little. In the current climate where MVP is a perfectly good way to develop innovative new products, you can still scope the product to do too little. In the new product space, this could be a sign that you have not yet zeroed in on the innovation or value-add of your product. Similarly, any project that involves a data center deployment (or resources) and a commitment from partners can also be scoped such that the collective investment is more than the collective return on that investment. In the evolution of existing products, such a release might be characterized as simply too conservative. It could also lack focus and just be a little bit of stuff everywhere.
- Wrong stuff. Often overlooked as a potential pitfall of product scoping is a choice to solve the wrong problems. In other words the plan might be solid and achievable, but the up-front efforts scoped the project on the wrong work. This is simply picking wrong. The trap you can fall into is how you cope with this—by simply adding more work or on-the-fly rescoping the product to do more or change scopes. Wrong stuff is a common pitfall for evolving existing products—it is when the scoping efforts lacked a coherent view of priorities.
- Local or global optimization. Scoping a product is essentially an optimization function. For an existing product that is evolving, there is a deliberate choice to pick an area and re-optimize it for a new generation. For a new product, the MVP is a way of choosing a place in the value chain to optimize. This scoping can be “off” and then the question is really whether the adapting that goes on during the project is optimizing the right plan or the wrong plan. This optimization challenge is essentially a downstream reaction to having picked the wrong stuff. You can A/B test or “re-position” the product, but that won’t help if you’re stuck on a part of the value curve that just isn’t all that valuable. Is your optimizing truly about an optimal product or are caught in a trough optimizing something local that is not enough to change the product landscape?
Of course projects go wrong in so many ways, some major and some minor. In fact, part of product development is just dealing with the inevitable problems. Nothing goes smoothly. And just like Apollo 13, when that first glitch happens you can think to yourself “gentlemen, looks like we had our glitch” or you can stay alert knowing that more are on the way. That’s the nature of complex product development.
Approach to rightsizing
Rightsizing your project up front is a way to build in both constraints and flexibility.
Rightsizing is clarifying up front the bounding box of the project. If you’re clear about the mechanical and strategic constraints of a project then you’ve taken the first step to keep things on track and to make sure your commitment to your team, customers, and management to develop a product can be met. One way to think of these constraints is as the key variables for project scoping—you rightsize a project by choosing values for these variables up front.
Mechanical constraints are the pillars of a project from a project management perspective. You can think of these as the budget or the foundation, the starting point:
- People. How many people are going to work on the project? This is the simplest question and the easiest one to fix up front. A good rule of thumb is that a project plan should be made based on the number of people you have from day one. While many projects will add people over time, counting on them to do critical work (especially if the project is not one that lasts years) is almost certain to disappoint. Plus most every project will have some changes in staffing due to natural people transitions, so the best case is to assume new people can fill in for departing folks.
- Time. The next easiest scoping variable is how long your project will last. Whether it is weeks, months, or years you have to pick up front. Proponents of continuously shipping still need to pick how long from the time code is planned and written until that particular code is released to customers in some way—and of course that can’t be done in isolation if multiple groups have code to release. As with people, you can add more time but you don’t get proportionally more work. And as we all know, once the project starts just making things shorter usually fails to meet expectations :-) Many stakeholders will have a point of view on how long the project should last, but this cannot be viewed in isolation relative to what you can get done.
- Code and tools. For any project that is starting from an existing product, one should be deliberate about what code moves forward and what code will be replaced/re-architectected. Starting from an existing product also determines a number of mechanical elements such as tools, languages, and cloud infrastructure. For a new product, picking these up front is an important rightsizing effort and not the sort of choices you can revisit on the fly as often these impact not just the schedule but the expression of features (for example, native v. HTML5 app, or what infrastructure you connect to for authentication). Choosing the code up front will bring in many stakeholders as it impacts the scope of the project relative to compatibility, for example.
While each of these mechanical attributes are relevant to the product strategy they don’t necessarily define the product strategy. Commonly, products talk about release cadence as a strategy but in actuality that is an expression of the mechanical aspects of the project. Strategic constraints are the walls of your project that build on the foundation of your mechanical constraints. Your strategy is how you make choices about what to do or not do for the product. There are a couple of key strategic constraints to address up front:
- Big bets. Every project makes a very small, or even just one, big bet. For an existing product this might be a bet on a new user interface or new business model. For a new product this might be the key IP or brand new scenario. The big bet is the rallying cry for everyone on the team—it is the part everyone is going to sacrifice to make work.
- Customer. Every project needs to start off knowing who will be using the product. Of course that sounds easy, but in a world of scoping a project it means that every potential customer cannot be served by a project to 100% of their needs or wants. Knowing how you are delivering value to the relevant customers is a key rightsizing effort. If you’re building on an existing product and breaking with the past or building a new product, then by definition some folks will not see the product as one that meets their needs. It does not mean you will never meet their needs nor does it mean every customer like that will see things the same way.
- Long term. When rightsizing a project you want to know where you are heading. There are many ways to do this—some very heavy and some very lightweight. The context of your business determines how much effort to put into this work. If you know where you are heading over time, not just one release, then you can connect the dots from what is missing today to where you will be after one or more turns of the crank. A long term discussion is not the same as long term planning. Long term planning is a heavyweight way of making commitments you probably can’t deliver on—we all know how much changes in every aspect of the team, market, business, etc. But long term discussion allows everyone to get comfortable that “thinking” is happening. One way to think of this tool is to make sure the dialog is what the team is thinking about, not what the team is doing, so that the long term dialog does not morph into long term commitments.
The first step in building a product plan is to scope the product—rightsizing. It is common to fall into extremes of this step—being extremely minimal or being too broad. In practice, the context of your business contributes to determining what viable alternatives to rightsizing are. There are tools you can use to actively rightsize the project rather than to let the size of the project just sort of happen. Rightsizing the current project with a longer term view as to where you are heading allows projects to be scoped without compromising your vision. As with any aspect of product development, being prepared and knowing that these challenges are in front of you is the best way to manage them.
–Steven
###
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
###
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.
###
Learning by Shipping 