Ghost in the Pixel

Is it a product, an experiment, or a demo? Let me explain with a brief anecdote…

Recently a routine project status meeting (snoozer, right?) rapidly escalated into a contentious spat, with accusations flying about “lack of support” and “not valuing the results”. Whoa! Stepping back from the unexpectedly flared tempers I asked the Dev and PM leads a simple question: “So what exactly are we building here?” Because it had become sorely apparent there was a crucial, unstated misunderstanding which had led to this moment of tension. Ascertaining what exactly we’re building (and thus, for which purpose) would clarify practical concerns and prepare the team for what needs to be done next. Unfortunately, this project had been running along on so many parallel tracks with missed chances for clear communications, due to false assumptions all along. Whew.

But I digress. So, what exactly were we building? And what are the implications for each option? Seems there were three basic paths overlapping yet at odds with each other:

a) A product: This implies building a fully-formed, self-sufficient entity with proper data, networking, API hooks all set up for actual usage by a particular customer for achieving certain tasks. There’s a resolved & integrated sense of brand, features, utility, and style that feels complete and ready for public release. The goal here is delivering a wholly formed object or service of tangible value for business gain, and customer satisfaction!

b) An experiment: Following popular “start-up” and “lean” thinking, this implies creating something that is narrowly scoped, based upon an hypothesis, to help achieve proper product-market fit downstream. The goal here is minimizing risk, maximizing learning, and doing so with efficiency. The audience is limited, with clear expectations set about what to expect. Usually it’s a rough prototype of limited capability, with parts not functioning or simply hinting at future utility, as prompts for user feedback. And the expectation here is that it could all totally fail, as any experiment!

c) A demo: The reality for enterprise software is that there is a structured sales pipeline and customer engagement practice including wooing market analysts and vendors via exclusive previews or demos of what’s next. And yes…sometimes you have to design for the demo, to tell a certain kind of story that addressees marketing or sales goals. Demos can be simply “smoke and mirrors” or more robustly defined, but regardless, are tuned for a highly calibrated messaging purpose to stoke customer interest (although not necessarily feedback). 

It should be apparent that each path involves a different approach to resourcing and leveraging the design process accordingly. A product is a full-blown, complex, multi-party coordinated effort with critical dependencies spanning divisions. You need a fully coordinated design team effort, from concept to delivery, with every potential bug closed or gap sealed. An experiment is far more scoped down and thus forgiving with direct impacts on specific engineering and design needs—in the words of Herb Simon, “do what’s necessary yet sufficient” to be expedient. And a demo is a wholly different affair, with closer coordination with marketing and sales strategy members, that can be a tightly limited, even isolated, exercise, with zero impact on real engineering. The application and distribution of resources can vary, and it’s important to note the differences, as they impact the use of designers & researchers too.

(You could certainly serve multiple purposes, but it’s sensible to have a main target to strive towards, to keep everyone focused. Anything incidentally supported becomes a secondary benefit, that’s welcomed but not a distraction. That expectation must be firmly conveyed!)

Getting back to my situation, those accusations of “lack of support” or “lack of interest” in the results, well…they were suitably corrected by clarifying what we need to support for, and what kind of results we’re all expecting to strive for. While a sparkling demo is important to impress future customers, a diligently fleshed out product for customer usage is arguably more valuable with significant efforts needed to enable market success. Understanding this difference can help a team ascertain their true goal and set proper expectations, across the board for everyone.

No doubt 2013 worked out to be another incredible year of inspiring conversations, insightful engagements, and cool opportunities! For that I’m extremely grateful to my friends & colleagues at work and within the broader UX/Design community. It is only through such relationships I’ve actually made it this far :-)

So, I want to briefly highlight my top personal accomplishments and valuable lessons learned for 2013, to hopefully serve as inspiration for others. 

 

Top Accomplishments

What did I do this year? A few items of note:

* Participated with top execs at annual Citrix Think Tank, to deliver a beautiful next-gen concept for a intelligent, contextual “agent” that enables work-life balance, cheekily codenamed “Gini” (combo of Siri + Google Now ;-) 

* Delivered innovation with Citrix Labs on multiple fronts (and with multiple trips to Sydney ;-) including a concept for multi-device, multi-touch communication codenamed “Crystal Palace”, resulting in some patent filings too! True design + tech collaboration via Lean UX model of experimentation and customer feedback, in a big way.

* Continued partnerships in design education, via General Assembly (lectures and hosted studio tours) & CCA’s DMBA Design Strategy programs. This fall I helped lead Citrix’s sponsorship of Nathan Shedroff’s Experience Design studio, with some inspiring results! Great stuff.

* Got involved with startups! This was a big year for me, via Citrix Startup Accelerator (running design sessions, scorecard reviews, office hours), Kleiner Perkins Design Council, and others too. Fascinating world of design opportunity!

* Mentored interns — yay :-) It’s always an honor–and a pure delight–to support our annual Citrix Design internship program via mentoring and networking events. Met some truly wonderful, emerging design stars! 

<<  Big thanks to my peers & leaders at Citrix for enabling such great stuff this year! Truly a team effort. >>

 

Valuable Lessons 

So, what did I learn from all that (and more)? Just a few things:

* Be adaptive to unexpected change–it’s essential: This is particularly true with constant organizational changes, departures, team evolutions, role changes, etc. It’s never personal but purely transactional, business-driven motive, what’s best for the Company. This can be hard to understand when emotional attachments to projects and teams form; just remember there’s an underlying strategy and being adaptive keeps you flexible– and optimistic! Plus, new opportunities almost always appear when you least expect it, from such changes. Which leads to…

* Be selfish–for your career: When great opportunities present themselves, go grab them! Don’t feel guilty about it. Sounds cut throat, but it’s not–it’s simply business! Nobody cares more about your career than you. And if you’re that fire-starter, provocative type of designer (umm, ahem, like me ;-) you kinda have to promote yourself through self-directed actions and relationships, so take advantage accordingly. However, always remember to…

* Be generous–for your team: The flip side is being truly generous with the opportunities you partake, sharing all benefits/results/takeaways with your teams, both peers and superiors alike! The karmic cycle of virtuous giving prevails, always. Pay it forward! This suggests a symbiotic relationship with your peers & superiors, for a productive healthy dynamic at work. 

* Everything is political–gotta learn “quiet influence”:  It’s simply human nature! This is true at the highest levels of leadership, where egos, domains, structures, and roles clash… along with typical conflicts over resources. Not fun! However, the ability to subtly detect various weak & strong political ties (see Dave Gray’s “The Connected Company”)  with influence patterns is vital, while persuasively (and persistently) pushing the “quiet influence” of your ideas. Not easy at all. But through confidence, conviction, and respectful “crucial conversations” you can thrive.

* Scaling is really hard–it’s OK to ask for help!: Scaling from a team of 10 to a team of 175+ worldwide creates a variety of challenges (with 200+ “catalysts” too), including how to share/communicate/learn and keep everyone inspired with new ideas. I’ve learned to focus on local areas of impact, support small activities (weekly sharing sessions and such) and how to delegate, grooming others to be your rep in other Geos (“site primes”). 

* Virtual teams are great, but innovation needs presence: Having worked on a long-term innovation project with a team based in Sydney, I’ve got firsthand experience with this :-) Every trip to Sydney proved to be a catalytic event, accelerating understanding, creating novel ideas, and overcoming engineering issues. There’s something about “being there” that can’t be replicated (yet) with today’s comm tools. Design matters, but presence really matters a lot, to get designs delivered.

 

Contending with stiff constraints, often resulting in a watered down design vision, is a common burden all designers face. It’s a major source of friction, having to deal with the inevitable frustrations of hearing “No” from engineers ground down by “death march” schedules or nervous managers highly reluctant to address risks. Often the designers’– themselves worn by frayed nerves— respond with an impassioned, “Why can’t you…” or “Why is this so difficult…”

Such questions just persist the frustration and antagonism of an unhealthy conflict, perhaps even painting an unfair shade of whininess upon designers who simply wants a vision delivered per spec. I mean, is that so wrong?

Well, I have learned (quite painfully at times, I admit!) to handle such situations by raising questions that enable a more constructive, collaborative approach while poking into the flexibility of these constraints…

1) “Help me understand the issue”: I know, this isn’t really a question per se, but it’s an invitation from the designer to the engineer (or manager) to start a mutually beneficial, educational dialogue. Offered genuinely, it suggests a desire to want to learn more about the issues, conveying a sense of empathy, and strokes up the other’s ego a bit, now being seen as an expert whose knowledge is sought. Also, this phrasing gets everyone talking, thus listening and understanding, not accusing and defending, resulting in hostile vibes. A far more personable, complimentary approach than the accusatory “Why can’t you build this”.  Conducted well with healthy skepticism (the five why’s, etc), this dialogue can lead to discovery of underlying issues of a business or organizational nature, not just stubborn programming matters.

2) “What would it take?”: This is simply a re-framing that turns an accusatory, defensive questioning  into something far more productive, as a problem solving exercise to achieve the implementation goals. Again, it’s an invitation by the designer to empathize and learn about the details, encouraging everyone to brainstorm options to achieve a desired result. Then everyone can have a smart negotiation around precisely those success factors: schedule, budget, resources, skills, tools, etc. And perhaps even a revisit of fundamental purposes and principles, which is not a bad thing at all when tempers are high. 

3) “What if we…”: Finally, offering hypotheticals shifts everyone into a mindset that is exploratory and optimistic. Of course, with tight schedules and related pressures, minds close down into deeply myopic views of what’s feasible right here and now. And there may be just resistance. However, a tentatively offered “what if” prompt opens up unseen options, shaping a problem solving dialogue engaging the team’s creativity. For example: Maybe we don’t have to build everything this release but we can prioritize on two features, while we beta test a third next quarter. Again, this approach might involve a revisit of project goals and values. 

As you can imagine, these tactics can and should be used together in various ways, for collaborative exchanges with the team. After all, not every denial is truly an absolute  roadblock, but might be a desperate, hidden invitation to dig deeper into unseen issues everyone is simply too stressed to confront at the moment.

As designers, we can enable such crucial conversations that lead a more constructive relationship, ultimately for the customers’ benefit! After all, isn’t that why we’re all working so hard on this project, for this deadline? 

** Note, my assumption here is that we’re all dealing with rational, mature adult professionals on a team. Seriously, if folks react badly to these tactics, there might be some deeper personnel or project management issues! ;-) 

So what is it exactly to truly be a “Labs” entity, functionally and strategically? It frankly seems to be a bit of an overused buzzword last few years, appending “Labs” to a company brand to somehow convey a marketable quality of something techie and… vaguely innovative ;-)

Well, after some reflection upon my own experience this year working with Citrix Labs on specific projects, touring MIT Media Lab recently, and learning more about other top-level corporate labs like Disney, Mercedes, Google, etc. I’d like to share my thoughts on what I believe makes for a vital, creative “Labs” environment with strong business impact. 

Here are some aspirational qualities common to the more successfully oriented Labs environs:

** Has a willingness to try, experiment, risk anything, fail at everything, bound by a strong “Can-Do” optimism of exploration. Instead of traditional naysaying of a product engineering group, the instinctive reaction to novel ideas is “Sure, why not?” and see where it goes…

** Deeply embodies a “hacker ethos” of rapidly creating quick & dirty prototypes to demonstrate raw functionality, as a starting point for further investigation of UX & business potential.

** Is constantly hounded by the question: What’s the most efficient way to prototype the intended functionality and get it in people’s hands for evaluation? (As Eames advocated: “the most with the least”) This requires lots of shortcuts–Searching for open source libraries, frameworks, scripts, etc. 

** Has tons of tech brilliance and polymathic curiosity for anything and everything, from “genetic algorithms” to “solar race cars” to “nanobots” and beyond, including the mundane “everyday engineering” of how things work. Such a team should be like a diverse mix of sharpened, perfected instruments on a surgical table, skilled at a variety of tools, methods, and approaches.

** Continually learning and growing by virtue of constant experimentation on their own, surprising others with new tricks, not just “what’s due next week” but always hungry to explore and foolish enough to try “dumb hacks” that fail (echoing Steve Jobs’ advice). 

** And, certainly not least: This is the team that PULLS the rest of the company forward into the unknown, assuming risk with enthusiasm for what’s possible. Not an anchor that weighs down, but a rocket that shoots upwards. (think of a “moonshot” directive)

** Finally, has strong ties to business model canvasing of the invention, with market-oriented experimentation as well, with customer development activities (Lean, etc.). Else the bold invention sits idly by! Gotta adopt a “3-in-a-Box” approach with verifiable commercial potential. 

IMHO when several of such qualities start to fade and disappear, that’s when a corporate “Labs” team is no longer the vanguard but devolves into a bane of mediocrity, rather than a benchmark for future prosperity. Ooh, a bit harsh to say, I know ;-) However, as you look deeper, this is all not just about “Labs” per se, but the broader innovation function within a company. For any company to achieve innovative results, the aforementioned qualities, propagated deeply amongst the employees, will increase the probabilities of success, hence earning the label of “innovation”.

At the end of the day, a major part of a “Labs” (or more accurately, innovation) capability and thus mindset is how to support that notion of big risk adoption, united with the creative, expressive nature of a strategic Design function. In the intersections lies the power and opportunity. Such an endeavor requires earnest partnership, bounded by a strong yet flexible process and shared complementary values, in order to deliver viable creative innovations for targeted markets.

Today I heard Ben Davis of the Bay Lights public art project describe his process of achieving something that I dubbed a “magical impossibility”— overcoming a situation fraught with maddening concerns of donor financing, complex structural engineering, regulated maintenance tactics, homeland security, and the intra-city politics of obtaining permits. Whew. And yet! Through luck and persistence Davis was able to find the right artist to enable his vision of a “canvas of light” modulating along the intensely variable SF Bay Bridge (winds, traffic, weather, fog) to great acclaim. The result is nothing short of magical, in its mesmerizing illumination of “giant pixels of light” that defies truly daunting practical matters. As Davis explained it, the project’s success depended upon many hands-on conversations with planners and engineers, backed by imaginative prototypes that showed the vision–thus forcing naysayers to shift towards an engagement of “How can we make this happen”. Yup, prototypes matter and can spin up the momentum to enable a vision to become real, corralling the necessary peer support…even for a massive public art project that rivals the scale of 8 Eiffel Towers!

Another point that stuck with me was Davis’ approach to compromise: “I will not compromise but I will be very grateful for your generous support”. Hmm! I like it. That saying suggests to me that taking a positive, “pay it forward” approach to engendering the team’s generosity to believe in and make his vision real is far more worthwhile than the typical back-and-forth exhaustive “death march” of cutting a vision down to a bare minimum of feasibility that satisfies nobody. Who wants that? Indeed, to achieve “magical impossibility” it takes hope, generosity, belief and damn good vision backed by indefatigable persistence. That’s when something truly awe-inspiring happens! Simply gaze upon the Bay Lights to see the proof. (see also: Tesla, SpaceX, Google Glass, Nest, iPhone, etc.)