Archive for the ‘posts’ Category
Tools for a More Inclusive Workplace
Everyone is interested in im
proving the workplace relative to inclusion, diversity, and equality across many dimensions. Research continues to show that many of the challenges experienced by team members are rooted in the combination of unconscious bias or routine communication approaches that might date back to our earliest development. There are many tools and skills available for everyone (!) to do better and I wanted to share some that I recently experienced. Openness to the variety of tools available is a first step in improving the workplace.
This week I participated in one such workshop, The Ally Skills Workshop, created by the Ada Initiative. The workshop was held at Slack and facilitated by Leigh Honeywell. She works at Slack and is also an advisor to the Ada Initiative who has facilitated this workshop many times. Having participated in a large number of related trainings and workshops over the years, I wanted to offer this one as a low-cost, lightweight, and at the same time highly valuable tool for groups. I believe it is especially relevant and appropriate to the < 50 person startup environment, though of course broadly applicable (and used at many large SV companies).
It isn’t appropriate or possible to recap an experiential workshop. The mechanics of Ally Skills are straight forward. In groups of 15-40 people (men are the primary target but groups of all kinds are encouraged) the facilitator guides the group through 2-3 hours of scenario-based discussions in breakouts and then group dialog. It is very straight forward, low-risk, and eye-opening. For those worried about something being too “heavy” or “HR”, the creators of this workshop are engineers with a great history in technology companies so you can be assured the tone is right.
The resources including facilitator training are all available via Creative Commons on the Ada Initiative site. The Initiative is going through a transition now and soon more information will be available for how you can directly contact the right people for obtaining this training for your company or group. You can contact Valerie Aurora for more information.
The Ally Workshop slides, the presenter guide, as well as a video of the class being taught are all available: http://adainitiative.org/what-we-do/workshops-and-training/.
While I have your attention on this topic, I wanted to share some other resources that I picked up at the workshop this week courtesy Leigh:
- Planning an offsite? Here’s a guide to inclusive offsites that originated at Google and is available via Creative Commons: http://geekfeminism.wikia.com/wiki/Inclusive_offsites
- Need tips on inclusive event planning? Here’s a collection of resources compile from the experiences at AdaCamp gatherings for making sure you are thinking holistically about inclusion https://adacamp.org/. This covers everything from catering, registering, planning and more.
- More blog resources? There are tons of blogs and resources out there and here are a few that I would recommend checking out: http://geekfeminism.wikia.com, http://geekfeminism.org/, http://captainawkward.com/.
One super interesting article that Leigh mentioned is a research paper from 1970 about the “Tyranny of Structureless”. I think this is a remarkably relevant work to consider given today’s oft-expressed view that the absence of structure and process is the way to avoid bias and discrimination (TL;DR—the opposite is the case).
All of us should always be in a learning mode when it comes to forming teams and building products that represent the very best work of everyone contributing. I would encourage everyone at every stage in their career to be on the lookout for new tools and techniques or new perspectives that each of us can put to use. No matter where you are in your career or how aware you are of your own behavior, there’s always learning to be done.
Stress or Pressure?
This post is a verbatim reprint from a book I wrote with Marco Iansiti of Harvard Business School, One Strategy: Organization, Planning, and Decision Making (Smile link). The original content was from a Microsoft internal blog post dated April 23, 2008. More context is available in the book (Google Books link). Posts were written for the Windows team but available to the whole company at the same time.
One of the things that is really important to me is making sure working on Windows and Windows Live is a low-stress job. Stress is evil, in fact stress is defined as:
stress: strain felt by somebody: mental, emotional, or physical strain caused, e.g. by anxiety or overwork. It may cause such symptoms as raised blood pressure or depression.
The thing about stress is that it is both physical and emotional. Stress is all about a loss of control (anxiety). Loss of control comes from not really knowing the goals, not understanding what success looks like, and in our vernacular, about being random. Stress comes because the work required is incompatible with your capabilities or your view of success. Stress is about a mismatch between your reality and the reality of your manager or team.
Stress in the workplace is 100% incompatible with building great software.
On the other hand, pressure is all around us. We have pressure to succeed. Pressure to get the build right. Pressure to get the design right. Pressure to go live with content. Pressure is a motivator. Pressure is defined as:
pressure: urgency, as of affairs or business
The thing about pressure is that it comes from within. Pressure is about the plan. Pressure is about your own goals (affairs). By operating with a plan and the details of that plan were created by the team we transform what might be stress into pressure. Pressure comes because you want to be successful against the goals you have set out. Pressure comes because the peers you depend on are expecting you to deliver what was communicated. Pressure is about the constant force in our environment to deliver on the plan we developed together.
Pressure in the workplace is how we stay on our toes and put forth our best efforts. Performing under pressure, while challenging, is what helps us as engineers to make great choices and use the constraints to our (and our customers) advantage.
No one works well under stress—the physical toll is real and provable. Some folks don’t work well under pressure. You don’t have to put yourself under pressure, but we’re a competitive company and like a great athletic team we do want that effort to go above 100%, but we can do so in a constructive way by using pressure to our advantage.
We’ve got some pressure going on now on our team. IE 8 in the final milestone. Integrating the M1 build of Windows Live. Windows 7 moving to M3. We’re excited. The pressure is real. It is pressure like being in the World Cup because we know what got us here and we know what it takes to be successful.
—Steven Sinofsky
PS: Yes these words are similar. The beauty of words are the subtle differences that make them special.
PPS: I’m just excited to use the new build of LiveWriter – and the whole Wave 3 suite!
Privacy and Security: Less Rhetoric and More Product
Tim Cook’s recent remarks on privacy described as “blistering” or an “epic subtweet” amplified a discussion about the web and privacy. Given the polarizing framing of this topic, collectively as an industry (and beyond) we have been less than stellar at discussing these topics. We’ve also done a poor job at proposing broad initiatives to address concerns raised in the discussion.
We seem to be caught in that difficult situation of having defined the problem as requiring an all-or-nothing solution, which is never a good place to be because the reality is more nuanced. Dustin Curtis points out the nuance in this post Privacy vs. User Experience.
Rather than debate extremes that are neither desirable nor technically possible, I want to suggest there are technical problems that can and should be solved, and doing so would make the Internet a better place for people using Internet services and businesses providing services.
“Get Over It”
Way back before there were mobile phones, today’s search engines or social networks, or cloud computing, Sun Computer founder Scott McNealy said, “You have zero privacy anyway. Get over it.” Yikes!
The statement at the time had elements of truth, fear, and absurdity. It was pre-bubble, heck it was the 1990’s still and 1984 was still fresh on our collective psyche. The statement did however foretell a significant change in what was going to happen.
Such a debate is not new. While the scale is different, I recall three major products from reputable companies that introduced me to the absolutes and polarization of the privacy “debate”.
Robert Bork was nominated for the Supreme Court of the US in 1987 (and later failed confirmation in the Senate). One of the moments of the very contentious confirmation was the appearance of the nominee’s personal records from a video rental store (delivered to the press as a hand-written list). This was clearly a dubious act later codified to be illegal. I think for my generation, it was the first experience of how things would change in the digital age of record keeping via computer. At the time there were quite a few connections made to how the FBI maintained files on people, but this was the first time the “incriminating” information came from a benign consumer business.
Lotus Marketplace was a product developed in the late 1980s. It had the gall to collect data sources like US Census data and public phone number listings and put it on CD ROMs for marketing people to use with Lotus 1-2-3 to plan and analyze marketing campaigns. Even worse it had household and zip code level data about the US (all based on sources already in existence and available to businesses. Much debate centered on how one could take this data and potentially “triangulate” it to actually learn something about an individuals. Likely due to the massive outcry, the product was never released to the market. From this early experience we can see the combination of an existing data source and distribution of digital data changes the dynamic of privacy.
Credit card companies became famous for the offers inside your monthly statement in the 1980s—little paper inserts with offers to buy custom return address labels, go on cruises, or secure other financial products. Like confetti they would fall out of the envelope. These were the very definition of “junk mail”. Then the companies began to use your previous purchase history to target these inserts. If you were paying attention then you realized that junk mail started to look less and less junky. This “feature” turned into a fear that credit cards were selling your charging history to random companies. Of course that was not true (in fact such information was closely guarded). The way they worked was the credit card company would offer inserts matching specific target customers and insert them for a fee. Because financial companies were already tightly regulated, the path to today’s Byzantine opt-in/opt-out direct mail policies can be traced to this history.
Fast-forward to today and we know that the services we use amass significant information about how we interact with them. The medical establishment has my medical history available to a constellation of caregivers (and to me) that make delivery of quality care easier and faster. Credit card companies know my charging history and patterns and can alert me to fraud instantly (even if too often incorrectly). Netflix knows all the movies I watch (and even how much of them) and uses that to improve a highly valued recommendation engine. Pizza delivery services know what we order and can save time and effort by using that history (and also offer promotions based on that). Google Maps knows where I travel and when and proactively offers suggestions on when I should depart depending on current traffic. The examples are endless. In fact the benefits of maintaining my history of interaction with a service are immense and a deciding factor in which services I choose to use.
The risk that we have assumed on an individual service is that providers cannot maintain the integrity of their own services. This is a network technology risk as we have seen with Target or Home Depot. It is a human risk as we have seen with breaches like Sony where people set out to arbitrarily harm others. It is a national security risk such as we have seen with the recent attack on the federal government in the US, allegedly orchestrated by a nation-state.
The risk that a company will do “bad” things with the data it has as a result of using a service by all appearances is infinitesimal. Will some features feel creepy to some? Of course that is the case. Some people don’t like having their name and order remembered by the barista (a human form of big data).
The risk that a company will be breached and the data put to uses not intended by the company is not only there, but it is significant. This is a technology problem our industry needs to solve. One thing is clear and it is that the biggest companies are the biggest targets and the largest technology companies are (I would assert) the most savvy and adept at these issues. But the problem is incredibly difficult in a world of nation-states leading some attacks.
I am not a “get over it” person, but rather an engineer and product person that sees the desire of companies to use data to deliver far better services and that desire is leading to immense innovation in how commerce is conducted and the internet is used. At the same time this data is very attractive to bad actors for a variety of reasons and that is a technical challenge our industry will rise to as it has time and time again. This is first and foremost a security problem due to bad actors. The privacy challenges come from what happens with the data when used by good actors in the system and this is a much more nuanced challenge.
I do believe that if you simply want to skip using services that compile data then you should be able to opt-out of services or to simply choose to use alternative services, but there is no obligation for any given service to provide the non-personalized, non-targeted, non-historic version of a service. The market for such services is likely to shrink and that might be unfortunate. The free market is like that. Sometimes something highly valued at a point in time becomes non-economic or scarce as companies compete for a larger market. I don’t have an easy answer for customers that want to use the internet without a trail—I strongly strongly support the services and technologies that allow for that (encryption, tor, etc.). I think the evidence is that this is not where most people will go. Historically, if there is money to be made then businesses will be created to seek that opportunity.
But What About Web Privacy
Why all the kerfuffle over privacy, again? My view is that this is rooted in the experience of the web that is just getting worse and many are frustrated. Security breaches of private information compound this concern and are symbolic of technology challenges on the Internet. Security breaches are unrelated to privacy in the sense that breached systems are not ad-funded user profiles, but wholly orthogonal and essential line of business information. The challenge is that our collective experience on the web is the result of a mountain of technologies built out over the past 20 years in an effort to deliver services to consumers that are paid for by advertising.
The act of delivering services paid for by advertising is not only inherently good and beneficial, but also essential to the amazing spread and growth of internet services. It should be readily apparent that the rise of internet advertising supported services is singularly responsible for the mass scale growth of billion-customer services. That is only good.
It isn’t that all my data is in the cloud waiting to be mined—AT&T, Comcast, Blockbuster, American Express, Nordstrom, Safeway, Amazon, UPS, and more already had a crazy amount of information about me and I would love exactly none of that to be in the hands of a bad actor. Even Apple knows every song I ever bought (if this happens to leak, I am saying now that I bought Barry Manilow Live for a friend’s birthday party), every place I ever used Maps to visit, and all my mail and contacts. Google has much of this too. I know Google is not selling my name and that information to anyone, but like a credit card insert they will match an advertisement for services to “people who visit New York”.
The challenge is that in an effort to improve the revenue yield of services all too often technology solutions available were used, abused, or otherwise misused in ways that degraded the overall experience of the internet for too many. The problem is that web ads are awful experiences and getting worse. We need technical solutions to this 20-year pile of legacy features.
My view is that the horrible experience of browsing the web and seeing those ads that “interfere” with using the web, and fear that this experience will become what we all experience on the pristine world of mobile is at least partially and likely largely responsible for using privacy as the anchor of this debate. In Steve Jobs’ “Thoughts on Flash” he was completely accurate about the problems of the runtime. That runtime was used as the basis of ads. He may or may not have been against ads, but many people were quite frustrated by the technical execution of ads in Flash and so his appeal resonated. It is just few of us could do much about it.
The industry did not stand still. Over the years we have seen browsers add pop-up blocking. While advertisers were angry, people cheered. We’ve seen a dramatic rise in ad-blockers. Yet we still see a constant stream of complaints on the web about “wait 5 seconds to see your story” or user experiences that test even the most savvy gamer when it comes to finding and clicking the close box. But this is the technology choice on the web, not the nature of advertising itself.
Fixing the Web
I was a strong supporter of evolving the browser to support features that allowed consumers to choose how to secure their experience. From popup blockers to Do Not Track I advocated for this type of control. The reason was not because I am against “free” services or want everyone to browser anonymously without footprints. The reason is because the web got so messy that the recourse seemed to be to help people as individuals.
On a personal note, championing features like Do Not Track (DNT) was one of the more educational chapters in my own career. I had never experienced the “slippery slope” defense quite like that—the idea that a feature was just an on-ramp to the apocalypse would not overstate the reaction to such a feature. The argument against DNT was that overnight the free internet would vaporize, which was also the argument against popup blockers or the removal of Flash.
There are three parts of today’s web that are technology problems waiting for solutions. The solutions are either difficult or undesirable but I believe solving them would go a long way towards framing the debate as a choice between “selling your personal information” or “there will be no services on the Internet”.
¶ Ads are awful. First and foremost, today’s ad formats are relatively hostile to consumers using services. We all know that ads want to be noticed. That’s a given. The openness and programmability of HTML5 and browsers created an open season on the technology used in ads and while there is plenty of innovation there are more negatives. Even the biggest and most popular sites can grind a browser to a halt on a powerful desktop PC. With television, for years advertisers tried tricks like raising the volume of an ad in order to get you to notice. This was fixed in the US by government regulation in 2012 with the CALM Act. We need such a movement for the internet. I believe the presence of advertising networks and internet standards bodies already in place (that create standard ad formats) could easily create standards around fly overs, popups, tiny close boxes, interstitial timings, audio and video playback, and so much more. We of course don’t want to stifle innovation, shut off A/B testing, or otherwise become the government but certainly we can create better technology and designs for advertisement. The popularity of browser based ad blockers is not about “privacy” but just about a desire to read more stuff and use more services in some reasonable way, I would assert.
¶ Content responsibility is lacking. One of the biggest places where advertising meets real-world security concerns is when advertisements themselves are vectors for security exploits. The advertising networks of today are well-known repositories for the distribution of zero-day exploits and malware insertion. While one could fault the browsers for not being able to secure against this, one must also fault the ad networks for allowing this content in the front door. One can also fault the sites that host this. As a consumer visiting a site, neither the site nor the ad network act responsibly relative to this type of content. All will do takedowns but the effort to own up to this challenge is not what I think it could be (there’s plenty of hard work, but not enough). Ad formats themselves are part of the challenge. Should ads be allowed the full power of the browser and runtimes? Should we define a maximal set of capabilities that ads can use? There is lots to be done here.
¶ Accountability is non-existent. While we were working on “Do Not Track” one of the things that surprised me the most was the lack of accountability for some core information about people that I believe is a privacy challenge. Some have talked about this as the problem with cookies (again a polarizing way to describe something since I also like not having to sign into services I use all the time on my home PC again and again). But mostly this is probably the most unsavory part of the web when it comes to this issue of privacy and security. Quite simply, once I start using a site, especially if I am logged in, then the ability for that site to see and store my internet traversal history is just too easy. The accountability for this is nowhere to be seen. Even the most trustworthy of sites are in need of improvement along these lines. When I visit nytimes.com (just an example of an incredibly reputable site) I am visiting dozens and dozens of other web sites just on the home page. Below you can see a portion of the Web Page Privacy view from Internet Explorer showing all the URLs that compose a page. This is quite a surprise to most people who think that the links might go to a few photos or to some other servers for code or features. These are not subdomains of nytimes.com but whole other sites (honestly, do I really trust the domain ru4.com, which by the way resolves to “Perfect Privacy Incorporated” but has no home page or corporate information page). What are the privacy policies of these sites? What information do they get? Do they combine this information across their customers? It isn’t that they do this, it is that as a consumer I have no knowledge and as a site I visit the Times offers no transparency. This to me feels like a big challenge. I don’t mind the Times having my browsing history for the Times, not at all especially if I am logged on. I do mind all these companies with mysterious URLs following me around. When a company has my transaction history and uses it to deliver services it does not send that history to others, it has others send information to them to use the history. Why can’t sites implement ads and analytics in this manner? You can see the lack of accountability in the terms of service, as shown for the nytimes.com site below.
Solutions are on the way
I believe there are deep concerns that the mobile internet will devolve into the desktop internet and we will lose the clean slate we currently have. This would be a shame because we need ad-supported services on mobile as well. We know the current experience of using a browser on mobile is racing towards the desktop—ironically because the browsers are getting better with video, script and runtime support and more.
The recent announcements by Facebook and partners show how innovation can happen. By providing a mechanism for ad-supported content to appear within a Facebook app experience natively and in a format that does not (necessarily) support many of the bad practices of the desktop web my view is that advertising can be more natural and at the same time relevant. My hope is that the runtime and/or the policies do not support the arbitrary nature of the desktop web and the experience does improve dramatically and stay that way for a while.
While all of this is taking place in the consumer world, the business computing landscape is being altered by the encroachment of consumer services. The natural reaction of the enterprise is to disable or turn off this access, which many believe is a losing strategy. In this context the biggest concern I would bring is the notion that the business internet will live along side the consumer internet and all will be good. As a consumer when I use my mobile device for work and personal, I want that conflation to exist in the service data I use. If I buy books for my own personal interest but use them for work or even get reimbursed by work, then I want my Amazon profile to have that. If I use Maps to navigate to partners or customers I don’t wan to sign on and sign off or use a different Maps instance, but want to train a single instance. If I use a productivity tool for home and work, I want the usage and quality data to flow to the service so that the product gets better for how I use it. In all cases, the unified view of “me” makes everything I use better and that makes me a better employee using tools. I’d hate for IT to see privacy as another thing to enforce by degrading my experience.
¶ Ultimately, the web will continue to evolve and free services will continue to grow. That is super important to the future for the next 3 billion internet users. There will always be a distribution of views of how much information should be saved and what services will be valued. We should no judge each other on that any more than we can expect every service to cater to ever perspective on this topic. For a moment, we can look at the challenges we’re discussing and see the engineering and product development work that can be done. I believe we can collectively improve the current situation if we take steps to design new products and services that meet the needs of all parties.
# # # # #
The Lesson of “Don’t forget all the parts move”
Today’s WSJ has a book excerpt about the demise of RIM/Blackberry. It is a fascinating story but also has a core lesson for product managers (including myself) which is the lesson of “don’t forget all the parts move”.
While hindsight is always 20/20, when you are faced with a potentially disruptive situation you have to take a step back and revisit nearly all of your assumptions, foundational or peripheral, because whether you see it or not, they are all going to face intense reinvention.
In disruptive theory we always talk about the core concept that disruptive products are better in some things but worse in many of the things (tasks, use cases, features) that are currently in use by the incumbent product. This is the basis of the disruption itself. In reading the excerpt it is clear that out of the gate this reality was how the RIM executives chose to view the iPhone as introduced as targeting a different market segment or different use cases:
If the iPhone gained traction, RIM’s senior executives believed, it would be with consumers who cared more about YouTube and other Internet escapes than efficiency and security. RIM’s core business customers valued BlackBerry’s secure and efficient communication systems. Offering mobile access to broader Internet content, says Mr. Conlee, “was not a space where we parked our business.”
There’s a natural business reaction to want to see a new entrant through the lens of a subset of your existing market. Once you can do that you get more comfortable doing battle in a small way rather than head-on. You feel your market size will trump a “niche” player.
The problem is that such perspective assumes a static view of the market. You’re assuming that all the other attributes of your implementation will remain advantaged and the new competitor will fail to translate that single advantage into a broader attack.
What happens, almost all the time, in technology is that disruptive entrants gain ecosystem momentum. There’s a finite bandwidth in the best people (engineers, partners, channel) to improve, integrate, promote products. Once the new product appears compelling in some way then there’s a race to gain a perceived first mover advantage. Or said another way, the leaders of the old world were already established and so a new platform yields a new chance to a leader. There’s a mad dash to execute whether you’re building leather cases, integrating line of business systems, or selling the product.
When I read that first quote, I thought how crazy to think that the rest of the internet, which includes email and messaging, would not race to try to establish new leadership in the space. The assumption that everyone is sitting still is flawed. Or just as likely, many of those incumbents will choose to assume their small part of the blackberry world will move ahead unscathed.
In a platform transition, everything is up for grabs. If you’re the platform you have to change everything and not just a few little things. First, no matter what you do the change is still going to happen. It means that you don’t have the option of doing nothing. Once a new platform gains momentum and you start losing your partners (of all kinds) or can no longer attract the top talent to the platform you have seen the warning sign and so has everyone else.
As Blackberry learned, you can’t take the path of trying to just change a few things and hope that taking what you perceive as the one missing piece and adding it to your platform will make the competitor go away. You can see how this worked in the example of the Storm device introduction, which aimed to add a bigger screen while maintaining the Blackberry keyboard feel. In other words, the perception was that it was the screen that was the thing that differentiated the device.
The browser was painfully slow, the clickable screen didn’t respond well in the corners and the device often froze and reset. Like most tech companies launching a glitchy product, RIM played for time. Verizon stoked sales with heavy subsidies, while RIM’s engineers raced to introduce software upgrades to eliminate Storm’s many bugs. “It was the best-selling initial product we ever had,” says Mr. Lazaridis, with 1 million devices sold in the first two months. “We couldn’t meet demand.”
Storm’s success was fleeting. By the time Mr. Balsillie was summoned to Verizon’s Basking Ridge, N.J., headquarters in the spring of 2009 to review the carrier’s sales data, RIM’s senior executives knew Storm was a wipeout. Virtually every one of the 1 million Storm phones shipped in 2008 needed replacing, Verizon’s chief marketing officer, John Stratton, told Mr. Balsillie. Many of the replacements were being returned as well. Storm was a complete failure, and Mr. Stratton wanted RIM to pay.
Of course we know now that there were many more elements of the iPhone that changed and it was no single feature or attribute. Every platform shift involves two steps:
- Introduction of a new platform that does some new things but does many existing things in a suboptimal way.
- Evolution of the new platform to achieve all those old scenarios but in new ways that often look like “hey we had that back then”. For example, consider the rise of secure messaging, mobile device management, and new implementations of email. All of these could be viewed as “Blackberry features” just done in a totally different way.
That’s why all the parts are moving, because everything you ever did will get revisited in a new context with a new implementation even if it (a) means the use case goes unanswered for a while and (b) the execution ends up being slightly different.
On a personal note, I was a Blackberry user from the earliest days (because our team made Outlook and the initial Blackberry was a client-side integration). When I saw the iPhone I was one of those people fixated on the keyboard. I was certain it would fail because I couldn’t peck out emails as fast as I could on Blackberry. In fact, I even remember talking about how Windows phones at the time had touchscreens so if that became popular we would have that as well. That summer, I waited on line to pick up my iPhone and was convinced of the future in just a few minutes.
You would have thought I would have been prepared. Previously, I had experienced a similar lesson. I had yet to be convinced of the utility of the internet on a phone, which the iPhone too solved. Of course my lens was clouded by the execution of the phones I used most (Blackberry and Windows) and the fact that the internet didn’t want to work on small screens and without Flash. I would visit Japan several times a year and see the DoCoMo i-mode phones and was a big skeptic—my friends from Japan still make fun of me for not seeing the future (by the way, at that time SMS had yet to even gain traction in the US and friends from Europe found that mysterious). What I failed to recognize was that in the i-mode implementation a full ecosystem solved the problem by moving all the parts around. Of course i-mode got disrupted when the whole of the internet moved to mobile. So perhaps it wasn’t just me. No matter what happens, someone always said it would. But saying it would happen and acting are very different things. Though I do recall many exchanges with Blackberry execs trying to convince them to have a great browser once I used the iPhone.
The lesson always comes back to underestimating the power of ecosystem momentum and the desire and ability of new players to do new things on a new platform.
A while back I made a list of all the moving parts of the Blackberry collapse. You can read it here, Disruption and woulda, coulda, shoulda.
A Product Person’s Perspective on Enterprise Selling
An architectural diagram for enterprise selling. ↗️
Many of the technical founders I have the opportunity to work with are well-versed in the architecture and features of their products (and products in general), but when it comes to possessing a similar view of the sales process there’s a good chance they are staring at a blank whiteboard. That’s to be expected because the skills and experience to do enterprise sales, and to do it well, are earned in the trenches over many years. Selling, specifically enterprise selling, is not something that comes naturally to most product-minded people.
Note: This post originally appeared on a16z.com on May 20, 2015.
Just as with code, one can devise an architectural view of how enterprise selling works. And like code, it is best to approach the process of selling using an architecture, rather than just diving in and writing code. Unlike code, if you act in haste or otherwise squander an enterprise opportunity there’s not really a chance for a rewrite or undo so it is best to approach with caution. Of course I’ve made many of my own mistakes and have also had ample time to learn what it was I have done wrong or what invalid assumptions I held. This post is a framework to help make sense of all the motions and actions that go on in the scope of enterprise sales.
Most technology leaders are consistently amazed at the depth and sophistication in enterprise selling. Since most engineers or technologists have little experience big-ticket selling, other than perhaps buying a car, this isn’t a surprise. While you might not be a designer or engineer, as a product person you have an empathy or sense of the skills, roles, and processes used. The same usually can’t be said for sales and selling.
There’s really only one key factor that distinguishes enterprise selling from everything a product person knows, and that is enterprise selling ends with the product and starts with the enterprise. Of course that is the complete opposite of what one might normally think where everything starts with a product. Even with the most amazing and inventive product ever conceived, selling at the enterprise level and enterprise scale requires inverting your perspective. There’s an analogy many often understand. Most product people know you don’t build a product by starting with a specific technology just because it is new, cool, or novel. Rather one starts by solving a problem of some sorts where applying a technology creates an amazing new experience that addresses a need or solves an articulated problem. Enterprise sales is similar in that you don’t start with a solution (your product) and then get to the problem (customer need, articulated or not).
Enterprise selling ends with the product and starts with the enterprise.
There are tons of amazing resources on enterprise selling. Resources go from the specifics of sales motions for a single sales person all the way to models for setting quotas, organizing resources, and training the sales organization. Most every seasoned enterprise sales person has their favorite toolset and part of hiring and managing a team is empowering them to make use of the tools they are comfortable with (just like you would for engineers). One resource I value is the book SPIN Selling, which is sort of a classic and spawned a whole ecosystem of supporting tools and guides.
A framework for product people
At an abstract level you can think of enterprise selling as following three steps:
First you set out to build a relationship with the enterprise customer that rests on a foundation of a deep understanding of their unique context. This relationship is formed by learning about the customer and organization, including how they do what they do, what they are struggling with and where they are heading. The biggest risk in most enterprise sales cycles is assuming you know these things—that one bank is like any other bank, that all Oracle shops are similar, or that everyone is trying to rip out SAP or move to the cloud. Almost all failures in enterprise selling, or at least all deal closing crisis moments, are caused by rushing this step or failing to learn all that needs to be learned about an enterprise.
Second, you articulate your vision or view of the “world” and how given your understanding of the enterprise you can begin to talk about a view for how to add value to an organization. The notion of “adding value” is key to this dialog as “solving problems” can set you up to fail too early in the process. The reason for this is that enterprise IT knows all to well that any new system begins with sunk costs, reduced productivity, and in general a period of investment. All this happens before the return or value is brought to the enterprise.
Finally, the last step is to establish a partnership, based on a mutual understanding. You understand the enterprise. The enterprise understands how you aim to aid value to their organization. The partnership process itself is how you go about going from pilot to implementation to expansion, sometimes called land and expand.
Let’s dive into each of these briefly with the goal of offering a flow or outline of the sorts of actions and motions that should take place. It is worth emphasizing that there’s a lot of unique value in how a given enterprise account manager approaches a specific customer with a specific type of product — so I’m not implying this is a one-size-fits-all model.
Relationship
The goal of the first milestone is a strong understanding of what things are like within the enterprise you are selling. To a product person this is very similar to those first ideas in developing a product-market fit and needing to assess the potential for the market. Much of the early effort will be consumed by understanding if you’re even working with the right team or people within an organization, and often there are multiple parties. Too often a product person believes you start at the CEO and shortcut this step, but an experienced account manager knows great deals can die in the middle of an organization just as easily at the top.
Culture. First you want to understand a bit of the culture of the enterprise. How risk averse they might be (for example, where do regulations fit or how leading edge is the organization as a whole)? You want to understand a bit about how decisions are made and how technologies and products are evaluated. You want to make sure you are sensitive to the basics of how the company likes to do business (how formal, what times do meetings take place, where do coffee, meals, drinks fit or don’t fit, and so on). This is especially true as you venture to industry segments that are unfamiliar to you. If you’ve ever done business in a different country before a good mindset to get in is to treat the initial contacts with an enterprise with the same level of cultural sensitivity and learning—better to learn rather than assume when you’re in an unfamiliar environment.
Organization. Every enterprise sales person I have worked with begins to build out the physical and logical org chart from the first engagements. You want to learn the management reporting structure as well as the power You want to understand the budget and decision making processes. Great enterprise sales people also know that you invest in the full org chart and don’t just focus on the areas of most authority and power—you never know where an advocate or obstacle might appear from as a deal progresses.
Infrastructure. IT is all about infrastructure and understanding how the company really works will be key to speaking their language. Not only are all enterprises subtly different in infrastructure, they take great pride in the differences they maintain and the rationale behind those differences, no matter how odd or crazy they might seem. I remember once pitching Office to an enterprise customer that had customized the installation of Office uniquely for over 100 different job functions. Not only did I think this was nuts, it created a massive support burden for the company. But in their world this was key to their productivity and my job was not to “save” them but to show them how I made their job even easier with a new product (all that comes later, in this step you’re just learning). You need to understand all the basics of infrastructure from authentication, networking, BYO, approved apps, messaging, email, and more many of these environmental variables will almost certainly impact your solution’s applicability and deployment.
Needs. Once you understand the culture, organization, and the technical infrastructure you have the foundation to be able to understand the enterprise’s needs. This is often the trickiest part of the first phase because it turns out enterprise IT, even though they are experts in technology, most often express their needs in terms of their own understanding or expectations of what products can do. As you catalog and understand needs what you are really doing is learning how to bridge from the solution your advocates believe they want to a solution that might be a much bigger leap (and much better, but very different) than expected. The pressure to listen to customers and act directly on needs (often described as requirements) is intense and during the course of product development and sales will be a significant challenge to just about every company.
My earliest days working with enterprise customers taught me a lesson that I have to admit still makes the “here and now” product person in me a bit uncomfortable. It was told to me by a former IBM field sales engineer who said “I sold more product today based on selling the future product than I ever sold by just selling what was ‘in my bag’.” While that’s most decidedly a cynical view, the reality is that enterprise selling is never about what a product can do right this moment—that’s just practical given the purchase, deployment, and training cycles within a large organization. Therefore a huge part of enterprise selling is articulating your unique technology/world view in the context of the relationship you have developed.
Vision
To many this can sound like selling vaporware, an old term for software that never shipped. That isn’t true at all. This is about selling a broad concept that will both endure for years and take years to fully realize, but can start delivering ROI in the near term within a known time period and cost. Putting this in the context of startups, this is much like when you hear venture capitalists talking about the investment in the team relative to the idea or invention—everyone knows the maze from idea to product to business will change and scope the initial idea, but the bet on the team and people will endure.
Inspiration. What is your inspiration for the product? This is where you talk about the experience that led you rethink the landscape. In the enterprise space this is most often about revisiting assumptions that the industry has made about costs of technology, where there is hardware versus software, or some massive shift such as the move to mobile or the cloud. Relative to a startup, you can think of this as the founder’s story—what led the founder to start a company is very much in line with what inspired the creation of a new enterprise product or service.
Uniqueness. While your inspiration is important it is likely that may people will have the same inspiration. In fact, enterprise products often appear in waves when it appears as though many are doing the “same” thing all at once. If you are in enterprise IT, then for sure every single vendor meeting you have these days is about cloud, mobile, BYO, security, and more. In a sales motion, you don’t want to spend a lot of time being the umteenth person touting the “changing world” but want to quickly articulate the insight, secret ingredient, or radical implementation that you have that you believe is unique. Too often this can be viewed as marketing, but really this needs to come from your product core—what is it that you see that no one else sees (to paraphrase Peter Thiel). Building a better mousetrap is great, but ROI in the enterprise does not come from rip and replace getting you a 10% improvement, so your inspiration should be pretty significant.
Competitors. You are not alone. No one in enterprise IT believes you built the one and only product that does most of what you do. Coming to an enterprise sales engagement with a detailed understanding of competitors shows respect and acknowledgement of reality. There are two types of competitors you need to understand fully. First, you need to be versed in the current marketplace competitors and how you compare to them. Often the best tool to view this is a classic “magic quadrant”—just be forewarned you have to substantiate claims carefully and be prepared for the “fans” of competitors to confront you (and be prepared for your competitors to sell against your characterization). If you’re doing this right, you are not creating new comparison criteria but using incumbent/competitor criteria as a starting point. Second, you need to be versed in how the enterprise is already addressing (or trying to address) the problem space. This is just as much a competitor—in enterprise software the easiest product to buy is the one you’ve already got in place and no one gets fired for doing that. While you might be negative towards your market competitors, it is incredibly important to be respectful of implemented competitors or homegrown solutions even if some in IT might mock their own choices.
Roadmap. The key deliverable for a vision is your roadmap of where you are heading. A roadmap to a product person might look like a schedule and features and some in IT most certainly would love that sort of information. In practice, the sort of tool you want to employ is much less detailed and granular than a product roadmap. Instead, you want to use a roadmap to establish a credible view for how you intend to both refine your existing proposition and expand your solution space. Why is this so critical? Enterprise IT is all about planning and long term within the organization. Budgets, headcount, organization, and internal service relationships all depend on “knowledge of the future”. At the same time, IT also wants to build new capabilities within the company and your roadmap can become a part of the IT roadmap. Obviously everything here is a fine balance between “promise and deliver” and falling into the trap of “over-promise and under-deliver”. One personal example was the introductions of both Outlook and Sharepoint and how adding them to the roadmap caused significant consternation in how IT thought of Office, which then crossed from personal productivity to messaging and then server infrastructure. In hindsight, the introduction of a product literally brought together parts of IT that previously never worked together!
Partnership
Transport yourself a couple of months (!) from that first opportunity to meet a potential customer and you’ve got a chance to really start to sell a product. For most product people, this is about deployment but to an enterprise account manager this last phase is about building a partnership. There is a distinction. The goal is to become long term partners and the tactic is to get the software into deployment and usage, not the other way around.
This phase always takes a bit longer than expected and for the first customers of a new product is a great deal of collaboration between engineering and sales. In later stages this repeatable process tends to become the role of Customer Success. For early stage products and companies, this phase is the equivalent of product-market fit as you work with the customer to refine the product (and pricing and more).
Proof. The first step is literally a proof of concept. The goal is to get the product up and running in their environment which could be as simple as single-sign on or a few dedicated clients or as complex as deployment or an isolated network with server hardware. It is likely during this stage that you will need to gain access to data, users, and systems that make the proof more relevant. It is important to be flexible and patient because for many pilots this is the most frustratingly slow part of the process. Do keep in mind, most every IT organization routinely does dozens of PoC, proof of concept, deals a year across many departments so be careful not to count this as “done” but do count it as “success”.
Implementation. The implementation phase is the time when you go from PoC to a deployed solution, aka production, within a department or company. For those building their first enterprise product, they are often shocked at how long it takes to roll out a new service or system within an enterprise even after it is running and working. We often compare this to signing up for a new SaaS service when in reality most companies are filled with employees that are far more worried about failing to get their work done than they are excited to try new tools and change the way they work. While many think most of the learning happens during the PoC, the astute enterprise product person knows that the real learning and informing of future product features takes place during the phased-in implementation when the product is in use by a wider audience outside of IT (if applicable).
Expansion. From a business perspective, the implementation counts as “land” and the next step is to “expand”. Once you’ve landed and seen early success, your advocates within IT will want to explore different ways to expand—remember IT is like everyone else and when something goes well they want to get credit and get visibility for the solution. Expansion is really the accelerator for a business and as most experienced people will tell you, there’s almost always more revenue with customers already paying you than with starting all over again with new potential customers. Enterprise products should be equipped in both the business and the product to expand in depth and breadth of usage to maximize this phase of growth. There’s potential for a bit of friction here as sales wants to keep the price down and not partition product value in order to land the deal. Management incentives across sales, marketing, product, and engineering play a critical role in finding this balance.
Replacement. The very last step in the partnership with an enterprise customer is replacing an existing system. I purposely put this last because most every product person thinks that when you have a new product the first line of sales is to explain what the customer can replace or decommission if they buy the new product. Every IT person knows that this is exactly the very last thing you do and that the long tail on usage for any implemented system before actual replacement, no matter how inevitable. This is important to internalize in terms of building a partnership because every running system has a champion or advocate who bought and deployed the system so a poor selling technique is to challenge that person too early. If you play everything correctly, someday you will be the system that keeps running long after it should—that’s something to keep in mind!
* * *
If all of this seems like a lot of work and a great deal of calendar time, well then you read it correctly. Average enterprise sales cycles for seven figure sales are easily 3 months and often up to 9 months depending on pre-existing systems. While every once in a while there are shortcuts or magical products, by and large this is how enterprise selling goes. It also makes a lot of sense because you’re going to collect a lot of money every year and your product will become an important part of a business.
Africa’s Mobile-Sun Revolution
Solar panels are a part of the landscape in southern Africa. Here, two boys ham it up for the camera while playing around a large-form factor panel.
The transformative potential for mobile communications is upon us in every aspect of life. In the developing world where infrastructure of all types is at a premium, few question the potential for mobile, but many wonder whether it should be a priority.
Note: This post originally appeared in Re/code on April 29, 2015.
Many years of visiting the developing world have taught me that, given the tools, people — including the very poor — will quickly and easily put them to uses that exceed even the well-intentioned ideas of the developed world. Poor people want to and can do everything people of means can do, they just don’t have the money.
Previously, I’ve written about the rise of ubiquitous mobile payments across Africa, and the work to bring free high-speed Wi-Fi to the settlements of South Africa. One thing has been missing, though, and that is access to reliable sources of power to keep these mobile phones and tablets running. In just a short time — less than a year — solar panels have become a commonplace site in one relatively poor village I recently returned to. I think this is a trend worth noting.
Could it be that solar power, potentially combined with large-scale batteries, will be the “grid” in developing markets, perhaps in the near future? I think so.
It is also the sort of disruptive trend we are getting used to seeing in developing markets. The market need and context leads to solutions that leapfrog what we created over many years in the developed world. Wireless phones skipped over landlines. Smartphones skipped over the PC. Mobile banking skipped over plastic cards and banks.
Could it be that solar power, potentially combined with large-scale batteries, will be the “grid” in developing markets, perhaps at least in the near future? I think so. At the very least, solar will prove enormously useful and beneficial and require effectively zero-dollar investments in infrastructure to dramatically improve lives. Solar combined with small-scale appliances, starting with mobile phones, provides an enormous increase in standard of living.
Infrastructure history
Historically, being poor in a developing economy put you at the end of a long chain of government and international NGO assistance when it comes to infrastructure. While people can pull together the makings of shelter and food along with subsistence labor or farming, access to what we in the developing world consider basic rights continues to be a remarkable challenge.
For the past 50 or more years, global organizations have been orchestrating “top down” approaches to building infrastructure: Roads, water, sewage and housing. There have been convincing successes in many of these areas. The recent UN Millennium Development Goals report demonstrates that the percentage of humans living at extreme poverty has decreased by almost half. In 1990, almost half the population in developing regions lived on less than $1.25 a day, the common definition of extreme poverty. This rate dropped to 22 percent by 2010, reducing the number of people living in extreme poverty by 700 million.
Nevertheless, billions of people live every day without access to basic infrastructure needs. Yet they continue to thrive, grow and improve their lives.
This UN Millennium Development Goals infographic shows the dramatic decline in percentage of people living under extreme poverty. (United Nations)
While the efforts to introduce major infrastructure will continue, the pace can sometimes be slower than either the people would like or what those of us in the developing world believe should be “acceptable.”
A village I know of, about 10 miles outside a major city in southern Africa, started from a patch of land contributed by the government about six years ago, and grew to a thriving neighborhood of 400 single-family homes. These homes are multi-room, secure, cement structures with indoor connections to sewage. The families of these homes earn about $100-$200 a month in a wide range of jobs. By way of comparison, these homes cost under $10,000 to build.
While the roads are unpaved, this is hardly noticed. But one thing has become much more noticeable of late is the lack of electrical power. Historically, this has not been nearly as problematic as we in the developing world might think. Their economy and jobs were tuned to daylight hours and work that made use of the energy sources available.
Solar-powered streetlights have been installed recently — here under construction — increasing public safety and providing light to the community.
Several finished homes around a nearly complete streetlight installation that also illuminates a drinking-water well, enabling nighttime access to water.
In an effort to bring additional safety to the village, the citizens worked with local government to install solar “street lights,” such as the one pictured here. This simple development began to change the nighttime for residents. These were installed beginning about nine months ago (as seen in the first photo, with a closer to production installation in the second).
Historically, this type of infrastructure, street lighting, would come after a connection to the electrical grid and development of roads. Solar power has made this “reordering” possible and welcome. Lighting streets is great, but that leads to more demands for power.
Mobile phones, the new infrastructure
These residents are pretty well off, even on relatively low wages that are three to five times the extreme poverty level. While they lack electricity and roads, they are safe, secured and sheltered.
One of the contributors to the improved standard of living has been mobile phones. Over the past couple of years, mobile phone penetration in this village has reached essentially 100 percent per household, and most adults have a mobile.
The use of mobiles is not a luxury, but essential to daily life. Those that commute into the city to sell or buy supplies can check on potential or availability via mobile.
Families can stay connected even when one goes far away for a good job or better work. Safety can be maintained by a “neighborhood watch” system powered by mobile. Students can access additional resources or teacher help via mobile. Of course, people love to use their phones to access the latest World Cup soccer results or listen to religious broadcasts.
All of these uses and infinitely more were developed in a truly bottom-up approach. There were no courses, no tutorials, no NGOs showing up to “deploy” phones or to train people. Access to the tools of communication and information as a platform were put to uses that surprise even the most tech-savvy (i.e., me). Mobile is so beneficial and so easy to access that it has quickly become ubiquitous and essential.
Last year, when I wrote for Re/code about mobile banking and free Wi-Fi, I received a fair number of comments and emails saying how this seemed like an unnecessary luxury, and that smartphones were being pushed on people who couldn’t afford the minutes or kilobytes, or would much rather have better access to water or toilets. The truth is, when you talk to people who live here, the priority for access unquestionably goes to mobile communication. In their own words, time and time again, the priority is attached to mobile communications and information.
Fortunately, because of the openness most governments have had to investments from multinational telecoms such as MTN, Airtel and Orange, most cities and suburban areas of the continent are well covered by 2G and often 3G connectivity. The rates are competitive across carriers, and many people carry multiple SIMs to arbitrage those rates, since saving pennies matters (calls within a carrier network are often cheaper than across carriers).
Mobile powered by solar
There has been one problem, though, and that is keeping phones charged. The more people use their phones (day and night), the more this has become a problem. While many of us spend time searching for outlets, what do you do when the nearest outlet might be a few miles away?
It is not uncommon to see one outlet shared by many members of a community. This outlet is in the community center, which is one of a small number of grid-connected structures. Note the variety of feature phones.
When there is an outlet, you often see people grouped around it, or one person volunteers to rotate phones through the charging cycles. Above a picture of an outlet in the one building connected to power, the community center. This is a pretty common sight.
Small portable solar panels can serve as “permanent” power sources when roof-mounted. You can see the extension wire drawn through the window.
An amazing transformation is taking place, and that is the rise of solar. What we might see as an exotic or luxury form of power for hikers and backpackers, or something reasonably well-off people use to augment their home power, has become as common a sight as the water pump.
The plethora of phones sharing a single outlet has been replaced by the portable solar panel out in front of every single home.
An interesting confluence of two factors has brought solar so quickly and cheaply to these people. First, as we all know, China has been investing massively in solar technology, solar panels and solar-powered devices. That has brought choice and low prices, as one would expect. In seeking growth opportunities, Chinese companies are looking to the vast market opportunity in Africa, where people are still not connected to a grid. There’s a full supply chain of innovation, from the solar through to integrated appliances with batteries.
Second, China has a significant presence in many African countries, and is contributing a massive amount of support in dollars and people to build out more traditional infrastructure, particularly transportation. In fact, many Chinese immigrants in country on work projects become the first customers of some of these solar innovations.
People are exposed to low-cost, low-power portable solar panels and they are “hooked.” In fact, you can now see many small stores that sell 100w panels for the basics of charging phones. You can see solar for sale in the image below. I left the whole store in the photo just to offer a bit of culture. The second photo shows the solar “for sale” offers.
A typical storefront in this community, selling a variety of important products for the home. Solar panels are for sale, as indicated by the signs in the upper left.
Detail from the storefront showing the solar panels for sale. There is a vibrant after-market for panels, as they often change hands, depending on the capital needs of a family.
Like many significant investments, there’s a vibrant market in both used panels and in the repair and maintenance of panels and wiring. Solar is a budding industry, for sure.
But people want more than to charge their phones once they see the “power” of solar. Here is where the ever-improving and shrinking of solar, LED lights, lithium batteries and more are coming together to transform the power consumption landscape and the very definition of “home appliances.”
In the developed world, we are transitioning from incandescent and fluorescent lighting in a rapid pace (in California, new construction effectively requires LED). LED lights, in addition to lasting “forever,” also consume 80 percent less power. Combining LED lights, low-cost rechargeable batteries and solar, you can all of a sudden light up a home at night. Econet is one of the largest mobile carriers/companies in Africa, and has many other ventures that improve the lives of people.
Here are a few Econet-developed LED lanterns recharging outside a home. This person has three lights, and shares or rents them with neighbors as a business. Not only are these cheaper and more durable than a fossil-fuel-based lantern, they have no ongoing cost, since they are powered by the sun.
Several modern, portable, solar-powered LED lamps sold at very low cost by mobile provider Econet. The owner rents these lamps out for short-term use.
With China bringing down the cost of larger panels, and the abundance of trade between Africa and China, there’s an explosion in slightly larger solar panels. In fact, many of the homes I saw just nine months ago now commonly sport a large two-by-four-foot solar panel on the roof or strategically positioned for maximal use.
These two boys were hanging out when I walked by, and quickly chose a formal pose in front of their home, which has a large permanent solar panel mounted on the roof.
Panels are often on the ground, because they move between homes where the investment for the panel has been shared by a couple of families. This might seem inefficient or odd to many, but the developing world is the master of the shared economy. Many might be familiar with the founding story of Lyft based on experiences with shared van rides in Zimbabwe, Zimride.
A trio of medium-sized solar panels strategically placed outside the doors of several homes sharing a courtyard.
Just the first step
We are just at the start of this next revolution at improving the lives of people in developing economies using solar power.
Three sets of advances will contribute to improved standards of living relative to economics, safety and comfort.
First, more and more battery-operated appliances will make their way into the world marketplace. At CES this year, we saw battery-operated developed-market products for everything from vacuum cleaners to stoves. Once something is battery-powered, it can be easily charged. These innovations will make their way to appliances that are useful in the context of the developing world, as we have seen with home lighting. The improvement in batteries in both cost and capacity (and weight) will drive major changes in appliances across all markets.
Second, the lowering of the price of solar panels will continue, and they will become commonplace as the next infrastructure requirement. This will then make possible all sorts of improvements in schools, work and safety. One thing that can then happen is an improvement in communication that comes from high speed Wi-Fi throughout villages like the one described here. Solar can power point-to-point connectivity or even a satellite uplink. Obviously, costs of connectivity itself will be something to deal with, but we’ve already seen how people adapt their needs and use of cash flow when something provides an extremely high benefit. It is far more likely that Wi-Fi will be built out before broad-based 3G or 4G coverage and upgrades can happen.
Third, I would not be surprised to see innovations in battery storage make their way to the developing markets long before they are ubiquitous in the developed markets.
A full-sized “roof” solar panel leaning up against a clothesline. Often roof-mounting panels is structurally challenging, so it is not uncommon to see these larger panels placed nearby on the ground.
Developed markets will value batteries for power backup in case of a loss of power and solar storage (rather than feeding back to the grid). But in the developing markets, a battery pack could provide continuous and on-demand power for a home in quantity, as well as nighttime power allowing for studying, businesses and more. This is transformative, as people can then begin to operate outside of daylight hours and to use a broader range of appliances that can save time, increase safety in the home and improve quality of life.
Our industry is all about mobile and cloud. With the arrival of low-cost solar, it’s no surprise that the revolution taking place in developing markets these days is rooted in mobile-sun.
Photos by the author unless otherwise noted.
Hiring Your First Product Manager
As a technical or product-focused CEO/founder of a growing company, a challenge one eventually faces is making that first product manager hire. Like most founders, there’s a good chance that you’re seeing ongoing challenges balancing the ever-increasing workload as CEO and starting to feel that sense of distance from the product as the needs of sales, marketing, hiring, and more pull you away. You might be wondering how you can spend more time on what you love, the product, while recognizing as CEO you must grow the strength of the organization while also focus on the contributions that you can make uniquely from the CEO role.
This is where making the first product manager hire is necessary and also a unique challenge. Most of the time, this hire is postponed as long as possible. You can cover-up for this missing resource with additional late night mails, some extra last minute meetings, and so on. The time this really hits home is when feature work or decisions turn into re-work or re-thinking. That’s the sign it is time to hire some help. Engineering resources are precious and timelines are always tight—being the founder-pm-bottleneck is no way to iterate your way to product-market fit.
The short answer to this next step is two-fold. First, at an emotional level this is extremely difficult for most every founder (btw, in a big company if you are starting a new product team it turns out this same dynamic applies). It is likely you will talk to quite a few candidates and no one will ever seem quite right. Second, you are going to have to trust your team a great deal on the fit and in doing so adjust your own approach to product management as part of the on-boarding process.
Every situation will be unique and there is no single rule for what type of skillset, experience, or seniority will be right for you and your company. The most important thing to think through before you start the process is to agree between your co-founder(s) and team on the profile of the role you wish the new PM to play in the organization.
Traditionally this would be framed along the lines of a job description:
Seniority. Are you looking for a VP, Director, Lead? Most typically you start here but these descriptions might fall short of really defining the role and so you end up seeing a lot of candidates.
Domain. Perhaps you are looking to fill in a specific technology background as part of this hire? As the product evolves you might be expanding into product areas that could use additional strength from product management. The question is really how much this will change the bottleneck you might be seeing.
Skillset. Are you looking for a candidate with more of a design, project management, or engineering background?
Each of these are examples of necessary but not sufficient criteria in kicking off the search for your first product manager. Because the first product manager hire is so unique for a product-focused founder, it is worth offering a framework or characterization of the role that you might start with.
Once you arrive at characterizing the role, then you are in a better position to narrow the search by more traditional experience and skills descriptors. Each of these below can work with the key being clear on hire and in management what the expectations are for the new product manager.
Extra hands. Most every founder I speak with starts the description of needing an extra set of hands, eyes, ears—someone to offload some work to, follow-up, track down, etc. This is often a positive stop-gap and can certainly work short term. Medium to long-term it can also starve you of the opportunity to grow the organization or might mean you set yourself up for yet another product management challenge down the road. If you go with this approach then the important thing to watch is that you did not solve you bottleneck problem by just moving it to another person or adding a level of bottleneck-indirection.
Process chief. Are you looking to offload the unpleasant or less intellectual aspects of product management such as the details of tracking, documenting, and other “process” issues? It is quite natural to be very narrowly focused in hiring the first product manager to want this set of skills added to the team. It isn’t uncommon for engineering to also seek this addition. The good news is this is almost always helpful. The challenge is it also adds another person to the team for the short term but might not really reduce the load or bottleneck but could unintentionally add friction to the process. A careful balance is required.
Apprentice. Many times the goal of bringing on the first product manager is to reduce the risk of hiring a senior or experienced person and going with a relatively junior hire and working to grow him/her into the role that you actually need. This can often be the most comfortable approach for the team because there’s a clear view of who the boss is and relatively clear expectations with the new PM. Generally the challenge can be down the road when you bring in more product managers and have to decide if the apprentice is “senior enough”. To avoid this challenge the best thing to do is really put in place a true training and growing situation. You need to provide the right level of responsibility and feedback/mentoring. Sometimes the difficulty is in hiring at this level but expecting too much, too soon.
Mini-me. Another model I have seen is searching for that first PM that is a reflection of your own skillsets and experience—a mini-me. For many this younger-sibling approach can be comfortable and easy to model and understand. It is a matter of finding the candidate that shares your product point of view and vision, and then a way of getting it done. The interesting challenge with this approach is not the way it works, but the way it might not work. Will the new PM amplify not just your strengths but your weaknesses? Will this miss out on the chance to being more perspective, diversity of thought and approach, or new ideas into the team? Are you being imitated or copied?
Successor. The most difficult or bravest first PM hire is to hire your successor. In hiring this person you’re bringing on a person who will simply be the final voice in product management. This is a scary approach and depending on the direct responsibilities you have and where you are in the product-market fit journey this might be the best approach for you and the team. The challenge I’ve seen most often with this first hire is that the seniority level doesn’t quite match the organization yet. The new hire’s first step is to build out a team and bring on more people. This might be exactly why you’re bringing on the person (just as when you bring on less familiar functions) but generally isn’t the case for product management as most often the first hire needs to be hands on and will buy you some time or runway. On the other hand, often the right candidate comes along—one who has the right level of person contribution, domain knowledge, and scale experience—and that might make for the right fit.
Of course hiring the person that fits this description as well as all the right product skills could turn into a unicorn hire, so definitely be careful about over-constraining the challenge. Of course, hiring is just the first step. As you onboard, assign and delegate work, and manage a new product manager you will also need to be incredibly deliberate in your own evolving role in product management. All too often the most-fitting hires can run into challenges when there is a mismatch between intention and execution of product management responsibility.
One word of caution. If you are concerned or even “afraid” of hiring a strong product person with a point of view, perspective, or just streak of stubbornness then think for a moment. Are you labeling the person a poor fit for “culture” or are you actually more concerned that they might make your own personal transition more challenging? If you’re working to always bring on strong people, don’t compromise at this juncture.
Hiring the first or early product managers for technical/product focused founder(s) is always a big step and a difficult one. When done correctly it can be a positive and rapid accelerator for engineering and a positive for the company overall as it makes room for you as that leader to focus on the work you can do uniquely.
More Tanium Magic
For a just over a year, Tanium Corporation has been impressing enterprise customers with its special brand of Tanium magic — the ability to instantly learn anything you need to know about the PCs, servers, VMs, and embedded devices such as ATMs and Point of Sale devices on your network. About nine months ago Andreessen Horowitz was offered the opportunity to partner with Tanium and the founders David and Orion Hindawi, and we could not be more impressed with the progress and growth of the company. This week Tanium is adding some more magic to an amazing product.
Growing and Scaling
The Tanium team has been hard at work on the platform and in creating a great company. It is worth sharing a little bit about the progress they have made in less than a year:
- Tanium is deployed on over 10,000,000 endpoints, with individual customers managing hundreds of thousands of endpoints.
- Tanium is in broad deployment in over half the Fortune 100.
- Tanium is rapidly growing (and hiring) with a particular focus on expanding internationally.
- Even with growth on every metric, Tanium has stayed a cash-generating and profitable business.
Tanium’s product magic is matched by the team’s amazing leadership and execution.
Reimagining Systems Management and Endpoint Security
When customers first see Tanium, they are blown away by the speed at which IT can learn what is going on with the endpoints on the network. Tanium’s capability to navigate, interrogate, and act on even the largest enterprise network in seconds is the magic that fires up customers –networks comprised of millions of endpoints made up of PCs, Servers, VMs, and embedded devices. This 15-second capability is the foundation of Tanium magic and is unprecedented for large scale environments.
Traditionally, enterprises deploy Systems Management (SM) platforms to control their environments. Prior to Tanium, even the state-of-the-art tools require immense investment in agents, logon scripts, policies, signature files, databases, dedicated infrastructure (servers and networking), and more, just to provide base level information. These tools frustrate end-users and CIOs alike by choking endpoints, burdening networks, and offering up information that is approximate at best and at worse irrelevant, because it is outdated.
Tanium surpasses the state-of-the-art in systems management, which you’d expect from founders whose previous company built the leading tools of this generation before being acquired by IBM. Not content to stop there, Tanium’s ambition is much greater than improving on their previous solution, even if it is already “10,000 times better.”
That ambition is based on an important observation regarding today’s challenges in enterprise security, particularly the realities faced by the nature of attacks. Malicious attacks are no longer brute force attempts to penetrate the network firewall or simply blunt viruses or malware that indiscriminately seize endpoints. We’re all aware that today’s attacks are multi-step, socially enabled or engineered, and by definition circumvent network-based and traditional end-point protection. We’ve seen that in all the recent breaches across Target, Home Depot, JP Morgan, Sony and more, including Anthem most recently.
In every case, once a breach becomes known, the most critical job of the security team is to scope the breach, identify compromised endpoints, and shut them down. Traditionally security teams relied on network-based management solutions since those have the fastest and most familiar tools. In practice, quickly identifying all the endpoints with an unpatched OpenSSL version or all that match a known indication of compromise, for example, look much less like network security efforts and more like endpoint challenges, historically the domain of systems management. The problem is that systems management tools were designed for an era when most of their work took place logging on or during off-hours “sweeps” of assets, with results gathered over the course of weeks.
CIOs recognize that having a systems management team using one set of tools that can barely keep up with traditional demands and having a security team using tools that are only focused on the network edge isn’t ideal by any measure. Systems management is now an integral part of incident detection and response. Conversely, security and protection require full knowledge and control of end-points. Neither set of existing tools deployed in most environments is up to the task.
Tanium has been working with customers from the CIO and CISO and throughout the management and response teams in enterprises to deploy Tanium as a frontline and first response platform that reimagines the traditional categories of systems management and endpoint security. In a world of unprecedented security risks, BYO devices, and ever-changing software needs nothing short of a rethinking of the tools and approaches is required.
Tanium is a new generation of security and systems management capabilities that meets two modern criteria:
- Provide 15-second information on all endpoints. Open your browser, type in a natural language query, and know instantly every endpoint that meets a particular criteria or indication of compromise, IOC, (for example, running a certain process, recently modified system state matching a pattern, particular network traffic, or literally anything you can imagine asking the endpoint). Aside from instant information, the key new capability is being able to learn about any aspect of the running system even if it is something unforeseen or unplanned. Results are real-time, live, and refreshable instantly.
- Remedy problematic situations immediately. Given the set of endpoints matching the criteria, take action immediately by shutting down endpoints, modifying the system configurations, quarantining devices, alerting users, or patching the appropriate modules, all in seconds rather than days. Aside from being able to immediately deploy the remedy, the key new capability is being able to implement any possible remedy across all endpoints, even within the largest networks in the world using minimal infrastructure.
The most innovative products are those that provide new ways of thinking about problems or new approaches that break down the traditional category boundaries. Tanium is such a platform, and that is why enterprises are so enthusiastic about what Tanium provides.
Shipping New Capabilities
This week Tanium is releasing some significant new capabilities that further the vision of a new category of product that serves the needs of both systems management and security professionals.
Tanium IOC Detect. Open to a wide variety of highly-regarded third-party threat intelligence data and indicators of compromise templates, Tanium takes this data and continuously seeks to identify endpoints at risk in real-time. Tanium is able to match the widest possible range of system attributes and patterns without downloading client-side databases or signature files. Security operations no longer needs to sift through all of the intelligence feeds manually or script signatures to feed into legacy systems management tools. Instead, Tanium makes it possible to detect and remediate threats immediately at massive scale.
Tanium Patch. Tanium transforms a process that’s error-prone and time-consuming with the ability to deploy patches across hundreds of thousands of endpoints in seconds, with 99%+ reliability and no scripting required by the IT team. Using two of Tanium’s key architectural elements, the communications layer and the data transport layer, patches are deployed and installed with unprecedented speed and unrivaled minimal impact on network infrastructure. Since many security breaches require updates to endpoints to truly remedy them, Tanium brings together the needs of both security and management processes.
Tanium Connect. Tanium integrates its 15-second data into third-party security and management tools to make those tools more accurate and actionable. For example, Tanium’s ability to quickly see anomalies on endpoints can be used to create alerts in security information and event management (SIEM) systems. Traditionally this data would be impossible to collect or would be routed through existing systems management infrastructures, which are labor intensive and high-latency data sources. Tanium Connect provides the security operations data required to ascertain the threat and, because the data is only seconds old, the team knows it is worthy of investigation.
These are just a few of the improvements to Tanium’s 6.5 platform available this week.
Looking Forward
Tanium’s magic innovation uniquely positions the company at the modern crossroads of systems management and security tools. Tanium’s platform reimagines these categories, while seamlessly working with existing infrastructure, and adds a new level of value and capability to forward-leaning IT teams.
Given this superb team, amazing growth, and unparalleled innovation, we could not be more happy than to lead a new round of investment in this wonderful company. Andreessen Horowitz is incredibly excited to be partnering with David, Orion, and the Tanium team, and I could not be more thrilled with continued service on Tanium’s Board of Directors.
Note: This post also appeared on http://a16z.com/blog.
Frictionless Design Choices
No one wants friction in their products. Everyone works to reduce it. Yet it sneaks in everywhere. We collectively praise a service, app, or design that masterfully reduces friction. We also appreciate minimalism. We love when products are artfully distilled down to their essence. How do we achieve these broadly appreciated design goals?
Frictionless and minimalism are related but not necessarily the same. Often they are conflated which can lead to design debates that are difficult to resolve.
A design can be minimal but still have a great deal of friction. The Linux command line interface is a great example of minimal design with high friction. You can do everything through a single prompt, as long as you know what to type and when. The minimalism is wonderful, but the ability to get going comes with high friction. The Unix philosophy of small cooperating tools is wonderfully minimal (every tool does a small number of things and does them well), but the learning and skills required are high friction.
- Minimalist design is about reducing the surface area of an experience.
- Frictionless design is about reducing the energy required by an experience.
When debating a design choice, feature addition, or product direction it can help to clarify whether a point of view originates from a perspective of keeping things minimal or reducing friction. If people discussing a decision start from this common understanding, I bet a decision will be reached sooner. Essentially, is the debate about adding a step or experience fork, or is it about adding something at all?
Product managers need to choose features to add. That is what makes all of this so difficult. As great as it is to stay pure and within original intent, if you and the team don’t enhance the capabilities of your product then someone will do what you do, but with a couple of more things or a different factoring and you’ll be left in the dust.
Therefore the real design challenge is not simply maintaining minimalism, but enhancing a product without adding more friction. Let’s assume you built a product that does something very exciting and has a very low friction to usage and does so with a minimal feature set. The next efforts are not about just watching your product, but about deciding how to address shortcoming, enhance, or otherwise improve the product to grow users, revenue, and popularity. The risk with every change is not simply failing to maintain minimalism, but introducing friction that becomes counterproductive to your goals.
When you look back you will be amazed at how the surface area of the product has expanded and how your view of minimalism has changed. Finding the right expression of new features such that you can maintain a minimalist approach is a big part of the design challenge as well.
There’s an additional design challenge. The first people who use your product will likely be the most enthusiastic, often the most technical, and in general the most desirous of features that introduce friction. In other words you will get the most positive feedback by adding features that ultimately will result in a product with a lot more friction.
Product managers and designers need to find the right balance as the extremes of doing nothing (staying minimal) and listening to customers (adding features) will only accelerate your path to replacement either by a product with more features or a product with less friction.
Low-Friction Design Patterns
Assuming you’re adding features to a product, the following are six design patterns to follow, each essentially reducing friction in your product. They cause the need to learn, consider, futz, or otherwise not race through the product to get something done.
- Decide on a default rather than options
- Create one path to a feature or task
- Offer personalization rather than customization
- Stick with changes you make
- Build features, not futzers
- Guess correctly all the time
Decide on a default rather than options. Everything is a choice. Any choice can be A/B tested or debated as to whether it works or not. The more testing you do the more likely you are to find a cohorts of people who prefer different approaches. The natural tendency will be to add an option or setting to allow people to choose their preference or worse you might interrupt their flow to ask preference. Make a choice. Take a stand. Every option is friction in the system (and code to maintain). When we added the wheel to the mouse in Office 97 there was a split in the team over whether the wheel should scroll down or whether it should zoom in/out. From the very first release there was an option to appease the part of the team that felt zoom was more natural. Even worse, the Word team went and did a ton of work to make zoom performant since it was fairly unnatural at the time.
Create one path to a feature or task. You add a new feature all is good—you’re in X in your product and then you can do Z. Then someone points out that there are times when you are doing Y in your product and you also want to do Z. Where there was once one path to get to a feature you now think about adding a second path. Maybe that sounds easy enough. Then a few iterations down the road and you have 5 different ways to get to Z. This whole design process leads to shortcuts, floating buttons, context menus, and more. Again all of which are favored by your early adopters and add friction for everyone else, and also add code. Pick the flow and sequence and stick with it. The most famous debate of all between Windows and Mac was over right click and it still rages. But the design energy to populate context menus and the cognitive load over knowing what you can or cannot do from there is real. How many people have right clicked on a file in the Windows desktop and clicked “Send” only to be launched into some Outlook configuration dialog when it would have been frictionless to always know that insert attachment in mail works and nothing will fail.
Offer personalization rather than customization. Early adopters of a product love to customize and tweak. That’s the nature of being a tech enthusiast. The theory is that customization makes a product easier to use because every use case is different enough that the time and effort saved by customization is worth it and important. In managing a product over time, customization becomes an engineering impossibility to maintain. When you want to change behavior or add a feature but it isn’t there or moved you introduce an engineering impossibility. The ability in Office to reorganize all the toolbars and menus seemed super cool at the time. Then we wanted to introduce a new scaleable structure that would work across resolutions and input devices (the ribbon). The problem was not just the upgrade but the reality that the friction introduced in using Office by never knowing where the menus might be (at the extreme, one could open a document that would rearrange the UX) was so high the product was unusable. Enterprise customers were rearranging the product such that people couldn’t take courses or buy books on how to use Office. The constraint led to the addition of a single place for personalization (Quick Access Toolbar) which ultimately allowed for a much lower friction design overall by enabling personalized efficiency without tweaking the whole experience.
Stick with changes you make. The ultimate design choice is when you change how a feature used by lots of customers works. You are choosing to deliberately upend their flow and add friction. At the same time the job of designing a product is moving it forward to new scenarios and capabilities and sometimes that means revisiting a design choice perhaps one that is the standard. It takes guts to do this, especially because you’re not always right. Often the path is to introduce a “compatibility mode” or a way to turn your new product into the old and comfortable product. This introduces three problems. First, you have to decide what the default will be (see the first rule above). Second, you have to decide if/how to enhance the old way of doing things while you’re also adding new things. Third, you have to decide when down the road you remove the old way, but in reality that will be never because you already told customers you value it enough to keep it around. But adding compatibility mode seems so easy and customer friendly! Ultimately you’re creating a technical debt that you can never dig out of. At the same time, failing to make big changes like this almost certainly means your product will be surpassed in the marketplace. See this HBS case on the Office 2007 Ribbon design http://www.hbs.edu/faculty/Pages/item.aspx?num=34113 ($).
Build features, not futzers. Tools for creativity are well-known to have elaborate palettes for formatting, effects, and other composition controls. Often these are built on amazing “engines” that manage shapes, text, or image data. Historically, tools of creativity have prided themselves on exposing the full range of capabilities enabled by these engines. These vast palettes of features and capabilities came to define how products and compete in the marketplace. In today’s world of mobility, touch interfaces, and timely/continuous productivity people do not necessarily want to spend time futzing with all the knobs and dials and seek to minimize time from idea to presentation—call this the Instagram effect. Yet even today we see too many tools that are about debugging your work, which is vastly different than getting work done. When a person needs a chart, a table, a diagram or an image how can you enable them to build that out of high-level concepts rather than the primitives that your engine supports? I was recently talking to the founder of an analytics company struggling with customer input on tweaking visualization which was adding complexity and taking engineering time away from adding whole new classes of visualization (like maps or donut charts). You’ll receive a lot of input from early customers to enable slightly different options or adjustments which will both challenge minimalism and add friction to your product without growing the breadth of scenarios your product enables. Staying focused on delivering features will enable your product to do more.
Guess correctly all the time. Many of the latest features, especially those based on machine learning or statistical models involve taking action based on guessing what comes next. These types of features are magical, when they work. The challenge is they don’t always work and that drives a friction-filled user experience. As you expand your product to these areas you’re going to want to find the right balance of how much to add and when, and patience with guessing too much too soon is a good practice. For better or worse, customers tend to love features that guess right 100% of the time and even if you’re wrong only 1% of the time, that 1% feels like a much higher error rate. Since we know we’re going to be learning and iterating in this regard, a best practice is to consider how frictionless you can make incorrect guesses. In other words, how much energy is required to skip a suggestion, undo an action, or otherwise keep the flow going and not stop to correct what the software thought was right but wasn’t. Let’s just call this, lessons from “bullets and numbering” in Word :-)
Finally, a word of caution on what happens as you expand your customer base when it comes to adding features. Anything you want to do in a product can be “obvious” either from usage data or from customer input. The challenge in product management is to create a core set of principles or beliefs about how you want to move the product forward that allow you to maintain the essential nature of your product while adding new features. The tension between maintaining existing customers via stability or incremental improvements versus keeping pace with where the marketplace is heading is the classic design challenge in technology products.
It shouldn’t be much of a surprise, but a great deal of product bloat comes from adding the obvious feature or directly listening to customers, or by failing to stick with design patterns. Ironically, efforts to enhance products for today’s customers are often the very features that add friction, reduce minimalism, and lead to overall bloat.
Bauhaus to Bloatware
This march from Bauhaus to Bloatware is well-known in our industry. It is part of a cycle that is very difficult to avoid. It is not without irony that your best and most engaged customers are often those pushing you to move faster down this path. Most every product in every segment starts minimal and adds features over time. At each juncture in the evolution of the product there is a tension over whether additions are the right marketplace response or simply bloat.
This march (and tension) continues until some complete rethinking introduces a new minimal product addressing most of the same need but from a different perspective. The cycle then starts again. Operating systems, databases, instruction sets, peripheral connection, laptops, interfaces, word processors, and anything you can name has gone through this cycle.
This re-evolution or reimagination of a product is key to the long term viability of any technology.
By adhering to a set of design principles you are able to expand the breadth of use cases your product serves while working to avoid simply adding more friction to the core use cases.
After publication three typos were fixed and the example of personalization clarified.
That First Sales or Marketing Hire
One of the biggest changes for an early-stage and growing company is when hiring transitions from technical/product founders to the first sales or marketing hires. It is an exciting time of course but also one that can be very stressful. As much as that can be the case, there are a few patterns and practices one can follow to successfully cross that chasm or at the very least reduce the risk to the same as any technical hire.
It goes without saying that the challenge is rooted in learning how to recognize and evaluate talented people that possess talents and skills that you do not have and really can’t relate to from an experience level. Quite a few roles in companies are going to be “close” or adjacent to your own skill set, speaking from the perspective of a technical founder. If you’re an engineer then QA or product management aren’t far off from what you do on a daily basis. If you tilt towards product management, you’re interactions with designers are perfectly natural. In fact for technical founders the spectrum from design to product management to engineering and then QA all feel like your wheelhouse.
Branching out further to sales, marketing, communications, business development, customer service, operations, supply chain, manufacturing, finance, and more can get uncomfortable very quickly. I remember the first time I had to interview a marketing person and I realized I didn’t even know what questions I should ask to do the interview. Yet, I had worked with marketing closely for many years. Fortunately, I had a candidate pipeline and an interview loop of experienced interviewers to draw from. That’s not alway the case with a startup’s first hires.
The following are four challenges worth considering and a step you can take to mitigate the challenges if you find yourself in this spot.
Look only within your network. When sourcing your first potential sales or marketing hire, you might tend to tap into your network the same way you would for an engineering hire. You might have a very broad network but it might not be a first person network. For example with engineering you might know people from the same school program or projects you worked on or are deeply familiar with. But with sales and marketing you probably lack that much common context and your network might reflect people you came across with in work or projects, but not necessarily worked with in the same way you would have with technical hires. You might be worried about taking too much time to source candidates or concerned that you will burn a lot of time on introductions and people you don’t “know” well. Approach. The first step in a breakthrough hire process is to make sure you cast a wide net and tap into other networks. This process itself is an investment in the future as you will broaden your network in a new domain.
Define the job by way you know from the outside. Walk a mile in other’s shoes is an age-old expression and is very fitting for your first sales or marketing hire. Your initial job description for a job you never done might be taken from another company or might be based on your view of what the job needs to get done. The challenge is that your view of what needs to get done is informed by your own “outsider” view of what a job you haven’t done before might mean. Being a sales or marketing person is vastly different from what it looks like from the outside, looking in. If you haven’t done the job you tend to think of the job through the lens of outputs rather than the journey from input to output. Most jobs are icebergs and the real work is the 90% under water. Until you’ve watched and worked with an enterprise sale end to end or developed and executed on a consumer go to market plan, your view of what the job looks like might be a sales presentation or SEO. Getting to those deliverables is a whole different set of motions. Approach. Find a way to have a few “what do you do” conversations with senior people in the job function. Maybe take some time to ask them to define for you what they think the steps would be to get to the outcome you are looking for, rather than to discuss the outcome. These “what would it take” conversations will help you to craft a skills assessment and talent fit.
Hire too senior or too junior. Gauging the seniority of a candidate and matching that to the requirement for the role are often quite tricky early on. In the conversations I’ve had I tend to see founders head to one extreme or another. Some founders take the outcome or deliverable they might want (white paper, quota) and work backwards to find a hire to “execute” on that. Some take the other extreme and act on the basis of not knowing so bringing in a senior person to build out the whole system. The reality is that for a new company you often are best off with someone in the middle. Why is that? If you hire to too junior the person will need supervision on a whole range of details you haven’t done before. This gets back to defining the job based on what you know—your solution set will be informed only by the experience you have had. If you hire someone too senior then they will immediately want to hire in the next round of management. You will quickly find that one hire translates into three and you’re scaling faster than you’re growing. I once talked to a company that was under ten engineers and hired a very senior marketing leader with domain experience who then subsequently spent $200K on consulting to develop a “marketing plan”. Yikes. Approach. Building on the knowledge you gained by casting a wide net and by taking the time to learn the full scope of work required, aim for the right level of hire that will “do the work” while “scaling the team”.
Base feedback on too small a circle. Once you have a robust job description and candidate flow and ways to evaluate, it is not uncommon to “fall back” on a small circle of people to get feedback on and evaluate the candidate. You might not want to take up time of too many people or you might think that it is tricky for too many people to evaluate a candidate. At the other end you might want these first hires to be a consensus based choice among a group that collectively is still learning these multi-disciplinary ropes. Culture fit is always a huge part of hiring, especially early on, but you’re also concerned about bringing in a whole new culture (a “sales culture” or “business culture”) and that contributes to the desire to keep things contained. Approach. Getting feedback from at least one trusted senior person with experience and success making these specific hires is critical. You can tap into your board or investors or network, but be sure to lean on those supporting you for some validation and verification.
One interesting note is that these challenges and approaches aren’t unique to startups. It turns out these follow similar patterns in large companies as well as you rise from engineering/product to business or general management. While you might think in a big company the support network insulates you from these challenges, I’ve seen (and experienced personally) all of the above.
The first sales or marketing hires can be pretty stressful for any technologist. Branching out to hire and manage those that rely more than you on the other side of their brain is a big opportunity for growth and development not only for the company but for you personally. It is a great time to step back and seek out support, advice, and counsel.
Learning by Shipping 
