Learning by Shipping

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

###