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.
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.
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.
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!
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.