by Anupam Kundu & Maneesh Subherwal

<essay originally published in Agile Journal>

Introduction

“Smart may have the brains, but Stupid has the guts.” Have you heard this before? Diesel used it recently (but with a word more crass than “guts”) as part of its “Be Stupid”marketing campaign, arguing that it is better to be stupid and bold than smart and creative. It’s a terrible, uninspiring attempt to match up to the essence of Steve Jobs’s “Stay Foolish, Stay Hungry“ commencement address at Stanford University.

As business-technology consultants, we often meet bold, smart product managers who are willing to take risks to build and launch new products and services in the face of extreme uncertainties. However, we never advise these executives to stay “stupid” by continuing to run risk-laden experiments without having the “smarts” to review the results, distill the feedback gathered, and adapt by evolving their strategy. Staying stupid is not a smart option!

Responding to Change

Everything around us is changing rapidly, influenced by fast adoption of new products and services in a mobile, social, and distributed world. In one generation, we changed our preference from typewriters to computer keyboards to touch screen interfaces; increasing percentage of population are adopting mobile phones as the new vehicle for taking digital photos resulting in significant drop of market capital for large camera companies: Organizations across the globe, small and large, are struggling not only with change but also with innovating, adapting, and effectively reacting to the pace of change.

In an earlier article, Anupam provides examples of product managers in large organizations who follows ordered processes to improve efficiency and scale rapidly with pre-existing business models instead of looking out for new ones.  These managers now struggle to ship new products and create innovative business ecosystems, while their counterparts in smaller organizations successfully foster new business models and product innovation. The same ordered processes and organizational structures that once helped these large organizations to scale efficiently and create specialized silos across the organization now inhibit them from creative innovation and discovery of new business models.

In the midst of such a dynamic business environment, we have seen multiple product divisions overwhelmed and even wiped out due both to sudden market downtrends in usage and adoption of their products and to product managers’ making blunders while scanning for possible escape routes. Most product managers (and, for that matter, others in leadership functions) are trained to work in ordered and predictable environments; they rely on stable intuition and experience to handle all kinds of situations, without an appreciation of how a particular business outcome (especially a negative one) is affected by complex, ambiguous, and unpredictable circumstances.

Product Managers, usually blame this lack of visibility into blinding, brisk, roller-coaster shifts in user demand and market preferences (sometimes correctly) on existing tools, structures, and processes for their apparent inability to analyze, predict, and provide insight into usage trends, patterns, and forecasts. However, over-reliance on cookie-cutter analysis and responses to deal with unforeseen situations increases the possibility of failure, and not all situations can be solved by asilver-bullet approach. Sadly, it’s not only businesses but also social institutions such as universities, banks, and courts that function in an Industrial Age mindset, with order and operational efficiency as the primary goal without any appreciation for the flux that exists in the marketplace. They tend to fail in their attempts to handle the disruptive turbulence and ambiguity of our current times.

The following real-world examples further articulate the fallacies of experienced product teams using silver-bullet solutions with limited understanding of customer needs and wants and/or little analysis of unintended business consequences.

Example 1: Increase Top-line Revenue at the Expense of Debit Card Fees

Recently, Bank of America took a few weeks to respond and reverse its decision to charge customers fees for debit card usage. The bank undermined its customers by attempting to force them into a situation that may have been good for the bank’s bottom line but was not attractive to its customers. This encouraged other banks like JPMorgan Chase, PNC Financial, and CitiGroup to stop—and in some cases reverse—their experiments with debit card usage fees and to offer incentives to customers to use debit cards more.The late reaction by the banks may be an example of their senior policy makers’ inability or unwillingness to quickly embrace customer feedback and change their course of action, resulting in substantial damage in brand value

It also resulted in a movement to transfer money from the “Big Six” banks to community banks and credit unions, as well as providing smaller online banks the opportunity to run aggressive pro-customer campaigns.

Introducing bold, stupid, and risky market changing shifts is necessary to analyze, understand, and reshape the tolerance limits of an existing consumer base. However, not building in sufficient risk mitigation within such experiments increases the probability of severely damaging outcomes if the experiments go wrong.

Example 2: Communicate Effectively While Streaming Video

The CEO of Netflix, Reed Hastings, tried to contain the public backlash against his decision to split the company’s streaming and DVD services into two separate, disjointed companies, but it was not enough to stop customers from exploring competitive options like Amazon Instant Video, and Netflix lost significant market share. Facing tremendous criticism from subscribers, investors, shareholders, and media, Hastings announced the decision to kill the separate DVD service concept in a blogpost: “I messed up. I owe everyone an explanation.” Twenty-seven thousand angry comments and 5,000 frustrated tweets by beleaguered customers resulted in 800,000 customers leaving Netflix for other alternatives. Before this incident, Netflix shares traded at a price-earnings ratio of about eighty, based on favorable earnings forecasts. However, after this blunder, Netlfix shares plunged 60 percent in 2011 and the company is expected to post losses in 2012, as well.

Not surprisingly, Netflix competitors like Hulu, Amazon, Flixster, Ultraviolet, and Cinema Nowjumped at this mass disenchantment with Netflix, doing everything they could to make it easier for consumers to get their video content any time, anywhere. Netflix was once the darling of the masses because of its quick action and bold experimentation to outwit older players (e.g., Blockbuster) in the video rental market. However, Netflix’s bad business decisions and inability to respond quickly in a hugely competitive market have led punters to speculate on the company’s future.

Customers look for innovation and bold experiments that have customer insight and experience at their core, but any business decision that betrays the interest of the customer is surely going to invite severely negative reactions.

Example 3: Disrupt the Retail Status Quo

JC Penney’s (JCP) new pricing strategy, formulated by CEO Ron Johnson (a former Apple executive) is an interesting example of a bold decision to disrupt the status quo of retail sales at their stores. He recently unveiled a simple, three-point pricing policy—“Every Day,” “Month-long Value” (theme sales), and “Best Prices” (clearance)—as one of his initiatives to transform the retail organization into a potential twenty-first-century market leader. This is very different from the more than 600 confusing price points the company used before to influence customers’ impulsive, deal-driven decisions rather than focus on product and brand quality.

Many analysts predict a gloom and doom scenario. They believe that JCP’s products are too generic and homogeneous for customers to buy the new pricing concept and that JCP lacks the value proposition and true differentiation required to make an impact with this. However, this and other changes Johnson has suggested are based on prior experiences and insight from similar experiments at Target and Apple. The market may not be satisfied with the short-term loss in customer base and early drop in revenue, but the goal is not to play market gains for the daily trader. The goal is to rebrand the company with innovative ideas based on experience and followed by measurable action. JCP now has a new logo, new pricing, new store layout, new products, and new marketing campaigns—all in two months! These are bold moves, backed by insightful analysis and an understanding of consumer behavior.

Bold Experimentation with Continuous Inspection

Having the guts to explore new business models or perform new experiments is a compelling argument these days. Technological innovations and rapid globalization of the economy have made it easier to conduct quick trials (A/B Testing,Usability Testing, etc.) to do customer validation of new ideas and concepts, early and often. Without a few bold changes, one can never truly find out what works and what doesn’t. However, not having the organizational intelligence to comprehend properly the outputs from these trials and take appropriate actions could have serious consequences to the bottom line. There is an urgent need for product managers to balance the bold experiments with key insights into market trends and customer needs as they cater to varied business and customer demands. As we continue to operate in a global, hyper-competitive world, it’s imperative that we balance our experiments with the insight to make sense of them.

All

I have signed up for the Technology Entrepreneurship classes from Stanford. This is part of the (currently) free online classes that Stanford opened up to the whole world. I have successfully finished first two assignment and working with an international team of classmates on my third assignment.

Our goal is to create a tool / service for anyone and everyone who is interested in well designed quotations and shares them over the social network. A platform that allows to create and share your thoughts, beliefs, citations, phrases; quotes that inspire you through the unique use of imagery and design. You know something like “I always have a quotation for everything – it saves me from original thinking”. We created a business model canvas with key monetizing sources being partnership for printing or B2B channels with greeting card companies that look for well designed quotations – except in this case the designs will be crowd sourced by the service. As part of the assignment, we have to do some kind of lean start-up like Customer Validation. For customer validation, we created a little survey

https://docs.google.com/spreadsheet/viewform?formkey=dGJKUVhkOVJJN2RhdnJWeTUycEFCb0E6MQ

by Julia Salem

<re-posted from Oxford Technology Ventures blog with due permission>

Agile works well for products that need continuous improvement, but it could be hard to adapt to a new development process without taking time to adjust the process while people are learning. Here are a several reasons why Agile can work for your UX team.

Direct Access to Developers—More opportunities to meet with the developer because Agile encourages more communication.

See Your Work in Action Sooner—See the project come together as it’s being built and catch any issues within days rather than weeks.

Agile Requirements Work for the Team—As a group, the team agrees on how aspects of  the project will come together.

If the First Pass Doesn’t Work, You Won’t Be Stuck—Agile allows you to catch mistakes and failures quicker and propose a fix in the next iteration.

Progress Can Be Seen Almost Immediately—No longer do you have to wait for the whole product to be built before you can test it out.

80-hour Workweeks Are Gone—By wasting less time by only doing what is important in the project, you and your employees can almost cut your workweek in half.

Your Voice Is Heard—You get to talk directly with the developers to advocate in the process of building the product.

Source: usabilitycounts

by Pete Hodgson

Introduction

Smart-phone usage continues to soar, but the market is still primarily split across two dominant platforms (iOS and Android). In addition there are other platforms which either hold important market share in certain demographics (Blackberry) or have the potential to grow in popularity (Win Phone 7). Finally there are larger form-factor devices like the iPad and Android tablets of various sizes. If you’re developing a mobile application today you seriously need to consider which platforms you should be supporting and how best to achieve that support. 

In this article I’ll summarize the various different architectural approaches one can explore and select from when building a mobile app with cross platform support as the key driver. Decisions made in terms of one approach over another can affect your product feature set, quality, schedule and budgets. Finally it’s up to the team to decide on one approach over another, based on the ground level realities that affect decision making, however, I hope that the approaches listed here will be a guiding factor. 

Approaches for Cross Platform Support

The Pure Web Approach

In this approach the entire client-side portion of an application is implemented using web technologies – HTML, CSS, and javascript. Users access your application by opening a page in their phone’s web browser, sometimes via a bookmark stored on their home screen. With modern browsers this approach can still allow apps which operate even when totally disconnected from the web, courtesy of technologies like HTML5′s app cache.

Examples of this type of app are everytimezone.com (optimized for tablets), Barrack Obama’s mobile web site barrackobama.com (which you’ll need to visit via a mobile browser).

The All Native Approach

In this approach the same functionality is implemented from scratch on each platform natively. Since each platform uses a different language, there is no opportunity to share the implementation of common client-side functionality, and it must be rebuilt for each platform.

The iOS apps from Instagram or Mint.com are examples of this approach.

The Native Wrapper Approach

Tools such as PhoneGap allow a mobile web application to be embedded within a native wrapper. This allows access to device features not currently exposed via web technologies (for example, the phone’s camera or tilt sensors). Using a native wrapper also allows you to distribute your application in the various app stores.

See Wikipedia’s Android app or LinkedIn’s iPhone app as examples of this approach.

The Write Once Run Anywhere (WORA) Approach

WORA tools such as Kony or Titanium’s Appcelerator allow you to implement your application once with a cross-compiler which will generate native applications for each platform you are targeting from the common implementation. Some tools use an embedded interpreter and run your code in that interpreter, while others compile your shared code into a native language which is executed directly on the target platform. This approach can allow you to quite cheaply support multiple platforms natively (with a mobile web option too), but it can be hard to generate a polished experience.

Examples of this approach include United’s mobile apps (both native and mobile web) or the ScoutMob app on iOS, Android, and Blackberry.

The Hybrid UI Approach

The trade-offs between native and HTML are quite nuanced. Often different parts of a mobile app will have different usability requirements, tipping the balance towards web techologies in some cases and towards native in others. A hybrid approach involves a blending of both HTML and native UI componentswithin a single mobile app. For example you may implement some our your UI by embedding HTML within an otherwise ative iOS app. Alternatively you may overlay a native contact picker UI inside HTML content which you are displaying in a wrapper app.

iOS apps from Facebook, LinkedIn, Tumblr and Gmail are good examples here.

The Cross-platform Core Approach

This approach is similar to some WORA solutions in that you implement your core business logic once in a common language such as javascript. The distinction is that rather than using a tool to generate the native app UI you instead write it by hand for each platform. At runtime your common core runs in an embedded interpreter, driving the native UI components inside your app using a bridge. One nice side-effect of this approach is it leads to a nicely layered architecture, with non-presentation logic clearly separated from the presentation code. This naturally leads to non-presentation logic which is easy to get under solid test coverage, something which can be a challenge for other javascript-based applications.

Angry Birds is an interesting example of this approach (using Lua as the core language).

Overwhelmed? How to select an approach over other?

Obviously this is not the kind of question that can be resolved in a few paragraphs.

That said, following are few key situations that will guide you to understand how to approach this problem of selecting the right approach.

• If most of your application code will be presentation level and you want a really polished UX, you are probably best of going All Native.
• If you need to rapidly create a native app on multiple platforms and high UI polish isn’t important to you then you should seriously consider a WORA solution.
• If your application will contain a significant amount of business logic or will have lots of back-end service interatactions (rather than being focussing mostly on presentation logic) but you still want a very native feel then a Cross-Platform Core may be the best way to go.
• If you don’t want to be on the app store, want a broad platform base relatively cheaply, and are willing to settle with less-than-perfect polish then you might want to consider Mobile Web.
• If your app doesn’t easily fit into the above categories – for example parts of it must have a very polished experience on a few platforms while other parts need a broad shallow reach – then a Hybrid approach is a good candidate.

 Conclusion

Nothing specific to end this conversation, except to suggest, choose wisely when it comes to mobile platforms. Any feedback is welcome.

by Anupam Kundu

Product developent is always challenging, more specially so when you are already renowned for making products that shape and reshape how humans interact with technology. I’m referring to Apple, Inc. Everybody is eagerly anticipating the release of the new iPad 3 (or iPad HD as some bloggers are calling it).

With new retina display, quad core Apple processor and possible support for LTE on both Verizon and AT&T, iPad 3 is hyped to be a super hit – more than any of the other iPads released before. Despite all that jazz, I have my doubts about the success of Apple iPad 3. Here are few reasons for my skepticism

• No ‘Jobs’: The mere fact that Steve Jobs no more will be doing the launch for this device is a big risk to the success of iPad3. I’m not sure how much media buzz Tim Cook will be able to generate. It’s really hard to be successor to a larger-than-type CEO like Steve Jobs.
• Too many iPad sold:  Between April, 2010 and June, 2011, Apple sold roughly 25 million iPads. Also as per Q4 2011 Apple financial results, about 11 million iPads were sold only in that quarter alone.  With most folks (in the early adopter category) already having iPads, we may not witness a mad rush for buying a new one so soon.
• Android Tablets: are catching up fast. Ton of competition for iPad 2 from Android tablet makers both here in USA and globally have made people aware of the choices they have in terms of tablets. iPad3 runs the risk of being launched in a much more mature tablet market than ever before.
• FoxConn connection: The build-up of aluminium dust that caused two explosions in the iPad2 factories run by infamous FoxConn in China has earned Apple some bad PR.  Labor rights concerned tree-huggers and others close to them may shun iPad 3.

by Jeff Wishnie

<re-posted from Jeff Wishnie’s blog with due permission>

We live in a time of global revolution—a revolution enabled by technology and, as with all revolutions, driven by people. It’s not a socio-political revolution like the Arab Spring or the Occupy/99% movement—though those movements have been substantially enabled by technology.

This revolution is more mundane, yet deeply transformational. It is driven by two key technologies: Mobile Networks and Cloud-Hosted Services.

These two technologies give organizations—governments, giant international Non-Governmental Organizations (NGOs), social enterprise entrepreneurs, community organizations, and even individuals—the ability to:

1. Communicate readily with field staff, volunteers, and the beneficiaries of their services, however remote.
2. Scale their services to national and global levels.

This technology-enabled ability to “talk to everyone, everywhere, without a ton of technical expertise, and for not a lot of cash” is literally changing everything for people who live and work where there is little of the big infrastructure (power, wire-line phones, wired-Internet, highways,plumbing) of the “developed” world.

Paper and the Bad Old Days (they’re still here)

Much of the world runs on paper. Paper doesn’t need power. It doesn’t need software security upgrades. It’s available everywhere. But it’s a terrible way to collect and analyze the data you need to run your organization.

In 2008, as CTO of Inveneo, I worked on a project with the World Health Organization (WHO) and the Sierra Leone Ministry of Health and Sanitation (MoHS)—here’s a blog post about the project’s kick-off trip. The project was simple: replace the paper forms used in hospitals with an open source health statistics package. Not only was statistics gathering via paper slow, expensive, and frustrating, it was wildly inaccurate—an analysis of ministry data showed far more babies received their 3rd vaccination shot than received their 2nd shot. Think about it. How can a baby get the 3rd of something without getting the 2nd? Vaccination data, at least, was bogus.

Paper plus Landcruisers to carry the paper to headquarters is state-of-the-art in many parts of the world. And I’ll be honest—our project in Sierra Leone did not fully solve the problem. We replaced paper with data files, but a staffer from the ministry still had to ride a motorcycle around the entire country collecting files on a USB stick to bring them to HQ!

Last year, I travelled to Madagascar to work with Human Network International, an NGO that provides communications services to other NGOs. One of HNI’s clients manages a network of over 200 private medical clinics to provide sexual and reproductive health services. They told us that they had never—ever—successfully collected a complete monthly report on the services they had provided. Think about that a moment. Imagine running a business, running it foryears, and never once knowing accurately and completely, what you had done in any given month.

The good news is that with HNI’s help and the amazing ubiquitous infrastructure provided by Madagascar’s mobile phone companies (MNOs in industry-speak), this has changed. Monthly reports are rolling in, complete and accurate.

Now this organization is having crazy thoughts—like communicating directly with their patients to provide them critical health information and to hear directly from them about the care they are receiving. It sounds so simple, but it’s revolutionary: entire populations of people who have been lucky to receive any health services at all will be able to demand the quality of service they deserve.

Half a Revolution: Ubiquitous Mobile Networks

Remember the medieval concept of “aether,” an invisible element that fills every corner, every crack of the entire universe? It’s real. We’ve built it here on earth. It’s called the “mobile phone network,” and it covers the entire planet, almost. According to an International Telecommunications Union report from 2008, in 2005 82% of the earth’s population lived in range of a mobile network signal. The same report predicted that by 2011 90% of the world would live in the aether of a mobile network. Here is the section of the ITU’s ICT Regulation Toolkit that quotes the research.

I spent some time searching for newer figures, and Google failed me. But I suspect we’ve achieved far greater coverage than the report from 2008 predicted. Smarter, better-informed, better-looking people than I have told me that today somewhere between 95% to 98% of all humanity live in range of a signal. The vast majority of these networks carry data as well as voice. Some are slow (GPRS), some are fast (3G/4G), and all offer SMS. So in some form, data transmission (“the Internet”) is also ubiquitous.

Not everyone has a phone. The ITU report says that in 2006, “only” 50% of the world’s population had a mobile phone—which is still stunning—but that data is 5 years old. More recent data shows an accelerating trend to universal phone ownership. PhoneCount mashes up various data sources and estimates we are 90 days (as of this writing) from “everyone connected” day.

PhoneCount is overly optimistic. We are some distance from universal ownership. Often, “access” means one phone in a family, controlled by a man. There are stubborn pockets of unconnectedness, but, even noting these caveats, this is a revolution: for the first time in human history, (nearly) everyone can communicate, in real time, with voice, or data, to (nearly) everyone else.

The Other Half: Living in a Cloud

Phones are great. But phones alone are half the story. The other half is hidden away in dark, cool, warehouses in Oregon, Ireland, and Singapore. Stuffed with servers, these warehouses are what the marketers call the “Cloud.”

Why should anyone care? Two reasons:

1. Scale. Servers mean scale. 200 hundred doctors voice-calling headquarters with monthly updates may be a pain, but manageable; 1000 doctors is not. How does Facebook handle 800 million customers with only about 3000 employees? Servers!

1. It’s someone else’s problem. Most mission-driven organizations have very few information technology experts. Many of them have none. So unlike Facebook (with their thousands of tech geeks) they can’t build or run their own technology.

I think this is good. A Malagasy reproductive health NGO should spend its time being expert on reproductive health in Madagascar, not learning Linux, Ruby, PHP, Java or any of the rest of that technical mumbo-jumbo. Unsexy Cloud server farms are run by technology companies that handle some very complicated (and to be honest, pretty sexy) technical problems so that you and I can access the power of the Cloud without being particularly technical ourselves.

I’m not suggesting that mission-driven organizations aren’t capable of being technology experts; I just don’t think they should have to.

The Reach of the Cloud

But wait, you say, is the Cloud available in the developing world? No, not everywhere. But it is everywhere the Internet is, and it’s growing quickly.

As recently as 2009, there was no direct Internet backbone connectivity to East Africa—all traffic went through expensive, slow, satellite links. Since 2009, new undersea cables and land-based fiber-optics networks have brought massive capacity to East Africa. Kenya’s wildly successful mobile money service M-Pesa lives in the Cloud, running on servers hosted in Europe by Rackspace.

With Cloud-hosted services, technically expert companies (and non-profits) can offer scaled services (not technology) to mission-driven organizations. This is the key: they offerservices not gadgets. Gadgets have to be learned, operated, and maintained. The care and feeding of technology is expensive and difficult. Services are someone else’s problem!

Mobile+Cloud = Service Explosion

The combination of Mobile and the Cloud as a platform for scaled services (run by someone else) is a launchpad for massive innovation: (nearly) any organization can offer scaled services to (nearly) anyone.

ThoughtWorks’ Social Impact Program is very proud to have contributed to the development of several Mobile/Cloud services for mission-driven organizations. Below are brief descriptions of a few of these projects.

1. Simpa Networks—How does a company make solar power available and affordable to people in rural India when the upfront cost of solar equipment is 3 to 5 times a family’s annual energy budget (typically spent on kerosene and candles)? Low-upfront-cost pay-as-you go power backed by a Cloud/Mobile payments system! Watch Simpa founder Michael MacHarg describe their work.

1. CycleTel™—Georgetown’s Institute of Reproductive Health wants to bring their fertility-awareness family planning method to India. How do they scale this method, currently available to North American women in the form of physical beads to millions of Indians? Mobile (SMS) backed by Cloud-hosted servers.Read a case study about the CycleTel™ project

1. RapidFTR—Initiated by New York University’s Interactive Telecommunications Programand UNICEF Innovation, RapidFTR is an open source project that “Helps aid workers collect, sort and share photographs and information about children in emergency situations so they can be registered for care services and reunited with their families.” RapidFTR combines Smartphone clients with a server infrastructure that can be deployed in the Cloud so that people managing an emergency don’t have to wrestle with technology when they have more pressing problems. It can also be run locally if connectivity is unavailable.

1. DataWinners/Mangrove—collaboration with Madagascar-based Human Network International (HNI) and Columbia University’s Modi Research Lab, Mangrove is an open source framework for building mobile-data collection systems. DataWinners, built on Mangrove and operated by HNI in a Cloud-hosted service, provides mission-driven organizations with mobile-data collection capabilities through a zero-technical-skills-required self-serve web application.

by Meaghan Waters 

Introduction

New Product Development (NPD) in large corporations are fraught with challenges, specially for products that involve user interface. What are the options available for the product team to arrange the specialized and coveted UX (User experience) folks? What kind of talent they should look for? And what are the pros and cons of various structures used by different product teams? Meaghan Waters, Experience Design Consultant with ThoughtWorks (she is based out of Australia), shares her thoughts and recommendations for agile product owners and managers in this concise yet thought-provoking article. You can reach Meaghan at mwaters@thoughtworks.com.

Almost everyone putting together a product development team (specially for products with user interface) these days will look to include some form of Customer Experience focus in the team. With the rapid rise of social media and crowd sourced recommendations, user experience and user interaction have become critical differentiators. This welcome demand has created an unwanted problem – supply. How do you fulfill the need and how do you manage the UX teams? Specifically how do you manage these creative bunch within relatively  large organizations?

There are a number of facets in supplying UX (or customer experience, or experience design, or ) inside of a large corporation. The two critical ones that I wanted to touch on here are

• Individual skills – UX practitioners are not interchangeable: different UX  people can have very different skill mixes – the first question to ask is  how can you get the skill mix right?

• Structure –Once  you’ve worked out the skill set, you have to figure out  how do you get these people to work together to deliver products across the organization.

Individual Skills

One of the challenges of setting up and managing UX teams is that the skill sets are so diverse. The core competencies that are often seen in the UX space are

• Ethnographic research
• Behavioral data analysis
• Usability testing
• Interaction Design
• Experience strategy
• Information Architecture
• Content strategy/writing
• Visual Design
• Facilitation
• Business and/or Systems Analysis
• Front-end development

Different practitioners will have more or less competency in different areas based on past experience and, to some extent, natural inclination. So you need to be careful looking for the right talent for your team. Firstly, you need to know what type of projects your team are going to be working on so that you know what type of skills are going to be in demand.

Are you mainly working on application projects? Then you probably don’t need a lot of depth in Visual Design or Content Strategy, but having people with Business Analysis, Interaction Design and Usability Testing skills could be key. However if more informational websites are going to be a major part of your work then having those Visual Design and Content Strategy skills are essential and you’ll probably want to add in Behavioural data analysis and strong Information Architecture skills as well.

Have a look at your current and projected program of work and analyze around the skills. Do not just say “I need 5 UX people to cover our 4 projects”. That’s just the way to a lot of pain – pain for the projects as they may not get what they really need, pain for the practitioner as they feel key skills are unused while others are not up to the project’s demands, and pain to the UX practice as a whole as the skills mismatch has led to the perception that UX can’t deliver.

Once you’ve got the overall skills mix sorted out and the number of people nailed the next thing you need to figure out is the type of work involved in these projects as that will help you in targeting the right experience level. Here is a basic rule of thumb to follow:

• Mainly procedural = more junior practitioners
• Mainly original, complex work = more senior practitioners

Structure (or how do you organize and distribute these people for best results)

The structure really comes into play once you have UX practitioners (with different and relevant skill set) distributed across the organization are working on different products/projects. There are three standard models that can be used –

• Centralised/Internal Agency – The UX practitioners are directly accountable to the central team rather than to the projects that they have been assigned to. The UX team is seen as a gatekeeper and bottleneck for development (of any form): organizations usually find a way around this (by hiring their own UX folks) and soon the UX team ceases to have real impact and meaning. Basically don’t do this, it doesn’t end well.

• Distributed amongst product teams – The only accountability for the UX folks is to the project teams or product groups that hired them. You seem to end up with a bunch of isolated individuals, turf wars and duplicated effort. It can kind of work but is not really reliable.

• Matrixed – is an effort to smooth out the rough edges in the other two: centralized hiring and career management but co-located with product teams. I’ve worked in and managed teams in all three different models and the Matrix is definitely the most effective way of delivering good products and long term value to the organisation as a whole. It’s also seems to be the way most teams effectively working in agile environments are organised. You get the necessary UX people directly involved with and able to respond to the projects needs as well as being able to leverage the large skill pool of the UX team as a whole when the project needs it.

So how does a matrix model work? I have made an attempt to show that in the image below – if not understood well, then there is always the text to follow that up.

An experienced UX manager hires, trains and manages practitioners as part of a central team. Knowing their skill set and the business need, the manager assigns practitioners to particular products or business functions.

Practitioners are assigned to projects for substantial amounts of time to build up domain expertise but are rotated amongst different projects to maintain perspective and to ensure an aligned experience is being delivered across the organization.

Priorities on a project are managed by project owner, with UX manager providing regular coaching, UX QA, and helping with synergies between different projects.

Supports the growth of junior practitioners while giving senior practitioners the degree of autonomy they prefer

To Summarize

Managing the supply of UX practitioners is a tricky business but it can be solved by the use of those same techniques that have created the demand for UX in the first place – an ability to look beyond what the user says and uncover their underlying needs (the skills) and an ability to look at the overall system of use – not just one small piece (the structure).

by Shaun McGee

Shaun is a Lead Consultant with ThoughtWorks Inc., and hence my esteemed colleague. Like other ThoughtWorkers he is strongly opinionated about Agile principles and practices and he spares no chance to explain his stance on stuff. In this particular article, Shaun discusses candidly the role of documentation in software projects. Shaun cites how there is a qualitative difference between documents produced at different stages of a project and we better start recognizing those differences  now!

Introduction
“We have come to value…working software over comprehensive documentation.”
The Agile Manifesto speaks to the importance of focusing effort and attention not on the documentation we produce, but rather on the functioning product that results from our work.

Why do we write software documentation?  Traditionally, it was accepted that by thoroughly documenting the “what” (requirements) and the “how” (specifications) we would be able to effectively develop some software, much like the way careful planning and design can produce a bridge or a house. Unfortunately this just doesn’t work most of the time. You can spell out in great detail what an application should do and how the development team should produce it, but what we often find is that as the system grows from an idea into lines of code the underlying requirements evolve or the original specification turns out to be impractical or impossible.

For this reason many agile practitioners (like ThoughtWorks) recommend keeping the documentation to a minimum in favor of face-to-face conversation. While there might be a temptation to discard documentation entirely, we know that’s simply not practical; we need some level of documentation as a consumable for later steps in the process. Indeed the complexities of some organizations and the regulation of some industries may require substantial documentation to describe a software system as a deliverable. The important point here is to recognize which purpose (consumable or deliverable) it serves.

So if we’re not going to use these “specifications” to drive the development process, what will we use them for?

If the reason we need some thorough documentation is to satisfy a customer or internal stakeholders, then we should prepare documentation that frames the system in their terms. This might take the form of a user manual, detailed feature description, or training materials. If the purpose is to satisfy some regulatory requirement, we should produce system specifications that comply with that need. In both cases we’re talking about a description of what the system does rather than what we intend for it to do. That’s an important distinction because it can help us to divorce the tasks of “producing documentation” from the process of “conducting analysis” where it has traditionally been tied. The bottom line is that the types of documentation that are suited for these needs are often not useful as a blueprint for software development, nor do traditional requirements specifications typically reflect an accurate picture of what a system is unless we put extensive effort into maintaining thorough version control.

So if we’re not producing documentation up front, when will we do it and who should write it?

Why not make the production of supporting documents a discreet task that is part of the lifecycle of a user story? Let’s say a story typically flows through the following stages:

While there should of course be constant communication and collaboration across the team throughout the entire process, there is a team member who has primary responsibility for pushing the story forward at each of these stages. During the Analysis stage, a story is defined and molded by a Business Analyst. In the Development stage, software craftsmen (developers) turn the idea into working code. In the Quality Analysis stage, test professionals scrutinize the software and try to break it! The customer then evaluates the finished product to ensure it meets her needs and certifies it is Complete.

Let’s imagine that you can add an additional step in the process:

Once a collection of related stories reach completion, we can start to consider application features to be reaching a level of maturity. We can take this opportunity to document how a mature feature functions within the system. This can and should happen soon after these stories are completed. We would not, for example, wait until just before a release. If the team is working collaboratively, we should expect anyone to be in a position to contribute to to documentation. Try a wiki approach that allows the entire team to contribute to a holistic view of the system; team members who play different roles would likely have unique perspectives.

“Simplicity–the art of maximizing the amount of work not done–is essential.” (Principles behind the Agile Manifesto)

by Anupam Kundu

Agile Day 2011 (organized by Joe Krebs of Incrementor) was held on September 27th at Pace University. This the largest gathering in Manhattan focusing on agile project management and development practices and a great opportunity to listen and learn from local practitioners alongside industry experts and obviously engage in shameless networking. I volunteered for the event and also ended up providing some quality air-time at the ThoughtWorks booth (my employer and one of the sponsors of the event).

(the pictures are just one click away)

Listen and Learn: Fortunate enough to listen to key note presentations by Linda Rising and Amy Goodman. While Linda spoke about “Patterns of Change” that are critical for ushering in any new initiative (including serve food in contentious meetings) in an organization, Amy focused on how we can decide on which side of change do we want to be (“be the sword or the shield!?”). Other than these luminaries, there were interesting talks from Michael Mah and David Hussman who dabbled with metrics and challenges of agile maturity in organizations respectively.

Open Spaces organized by Rob Purdie was tremendously interesting and refreshing as the participants could decide on the topics that they wanted to speak or discuss about. My picks were pretty predictable – anything to do with agile and product management. Got involved in two open space breakout sessions – one run by David Hussman and the other by Jennifer Onggowidjaja. David challenged his audience to talk about product thinking – making the crowd appreciate that “What and Why” are as much important (if not more) as “How”. The small group of audience discussed the challenges faced in building up a solid backlog that truly represents the product and how they can possibly overcome those challenges (see images below). Jennifer gathered the attention of her audience by discussing processes to drive the product vision – things that you need to do well at the discovery phase so that the whole team have the context of product.

Shameless Networking: Like any other good conference, this one was also a sweet spot for networking. There were plenty of local companies and recruiters in the audience. A shout out to Pace University’s liaison and Program Manager Wilfredo (Freddie) who enabled the whole infrastructure set up for the event and was of tremendous help to me (in making sure that the food and refreshments got delivered on time and in plenty). The students at the Pace University who attended the session came across as very impressive and mature in their CS practice. Connected with a bunch of interesting folks who are using agile in different ways in their respective practices (marketing, remote client servicing etc.)

Here are few images from the conference. More are available here.