Learning by Shipping

products, development, management…

Archive for the ‘posts’ Category

Getting (the Right) Stuff Done

S65-42424A key role of product management (PM), whether as the product-focused founder (CEO, CTO) or the PM leader, is making sure product development efforts are focused. But what does it mean to be focused? This isn’t always as clear as it could be for a team. While everyone loves focus, there’s an equal love for agility, action, and moving “forward”. Keeping the trains running is incredibly important, but just as important and often overlooked is making sure the destination is clear.

It might sound crazy, but it is much easier than one might think for teams to move fast, get stuff done, and break things that might not be helping the overall efforts. In fact, in my experience, this challenge has become even greater in recent years with the availability of data and telemetry. With such, it becomes very easy to find work that needs to be done to improve the app or service — the data is telling you right then and there that something is tripping up customers, performing poorly, or going unused. Taking action makes it easy to feel like the right thing is happening. It feels like moving forward. Everyone loves to get stuff done. Everyone feels focused.

But is the team focused on the right work to achieve the right results?

Just a little process

Two important realities represent a constant balancing act when leading a product. As a PM you are applying finite resources to market needs in the march towards product-market fit or are working furiously to maintain a competitive lead. In addition to the new features there is the work that sales or customer success needs and together those greatly exceed what can be delivered by engineering.

This problem doesn’t ever go away and is at the core of the role of product leadership — getting the right stuff done with the right priority.

In every well-run company there is a strong tendency towards action and a strong dislike (tending to revulsion) of process. In practice, the absence of a process is just as much of a process, just one without clear lines between action and result. A little bit of process (aka product management) can go a long way to having real focus and getting the right things done.

With a little bit of process, everyone on the team can have:

  • Shared views on what success looks like
  • Clear understanding of success measures and metrics
  • Easy mechanism to decide what should be cut or pushed out when things aren’t going as planned
  • Visible alignment between what work will impact what elements of success and which measures
  • Honest accounting of resources going into what big picture initiatives
  • Ample opportunity to participate in deciding what gets done and when

It is very easy to overdo process and go from a helpful tool to a burden people run away from. A personal goal has always been to be as lightweight as possible and to have a way of thinking about these needs that scale from projects that last weeks, months, or even longer.

My guiding principle or golden rule of process is to never ask for something from someone that does not directly help them to get their own work done. Process is not about reports or “management”, but about making sure the work each person does is the most important work to do and the time.

Just a little framework

When most people think of coming up with a product roadmap or plan, they think of ends of a spectrum. At one end there’s commonly the one slide version labeled with months or years and a couple of bullet points at varying levels of granularity and decreasing accuracy as time goes on. There’s also the detailed and long-term strategic plan that most people can’t read through that is often the work of consultants or staff at big companies.

There’s something in between that I’ve found very helpful in terms of framing the product roadmap.

The roadmap can be represented as a hierarchy of increasing detail. It starts with a mission covering years of aspirations for the whole company. From the mission follow the goals representing the 12 months of work supported by specific metrics or measures and the various roles or disciplines in the company. Teams then come together to work on projects (or milestones in a longer term project) that take weeks and are delineated by releasing product or programs to the market. Supporting the creating of projects are the day to day tasks at the feature level representing the work of individuals.

Throughout this whole system there is ongoing telemetry that is called upon to support the company with reliable data upon which to make decisions.


Whole books have been written about mission statements or the process of developing a mission statement. Nothing makes me groan more than the idea of having a meeting to craft out a mission statement. We’ve all seen the results of these efforts that are an awkward combination of passive voice, comma splices, and breathless language. Companies exist for a reason and that’s the mission.

Missions are aspirational and guide you for years and represent the reason for being. Everything you do should aim towards your mission, and how you do that is the work of the rest of the framework. Missions boldly stating that the goal is to “disrupt” tend to be a bit backward looking or focus on the mechanism versus the outcome. Rather a mission that defines a future state of being or a new world view are often the most enduring and more positive. The most important thing about a mission is that there is just one and it endures. Mission statements are best able to be expressed on t-shirts, or something close.


Most everyone thinks they already have goals. Too often though goals are expressed as metrics or scorecards, like be the most downloaded app or number, daily users, or bookings. These are easy to express and are the lifeblood of a startup. The challenge is they change frequently. Like any good code when faced with something that changes frequently, the best bet is to add a level of indirection. A goal is the abstract view of metrics or measures.

Goals are strategic concepts such as retention, ease of use, acquisition, manageability, scale, success, and more. Through evolving telemetry you develop metrics to support the goals.

By using these abstractions you might come realize you have more goals than engineers (or marketers, success partners, etc.) or that you end up with every person working on too many goals. This is part of the process of being focused about goals. For any one product there can only be 3–5 goals and those fit on one “slide”, which includes the full spectrum of engineering, sales, and customer outcomes. This is a deliberate attempt to put in place some constraints up front.

Goals are then measured in specific ways over time. Metrics are then the lifeblood of goals. Your goal might be acquisition, but the metric might be a specific mechanism of retention for a period of time; or your goal might be to improve scalability of the service but the measure might be compute usage for some time and then storage usage for another.

When thinking about goals, they almost always fall to a specific function (or role) on the team such as marketing, sales, or engineering. Having a full accounting of the goals and the associated metrics allows you to understand what will change as the team’s work progresses — what is measured will be what changes.


Projects are easy to understand — they are the releases or programs customers and the marketplace use and hear about. A project might be, for example, a full update to the service, the app, a new entry to the market, a launch, a campaign, or a major infrastructure change. Early on it is trivial to name the projects for a company. Very quickly, however, the number of projects can balloon and become increasingly difficult to track (and potentially to justify). There are SDKs, enterprise tools, segment campaigns, apps for different platforms or support for different browsers, and more.

The key reason to maintain a clear list of active projects is because momentum in continuing some project, failing to re-allocate resources, can often be the biggest constraint in getting the important work done. It common to find yourself in the situation of maintaining a project that no longer fits with the immediate needs but there’s inertia that makes it hard to change. The most important task for product management is to make sure everyone is aware of the projects being undertaken. The more the company scales the more critical it is to know what projects are active and what commitments the team is making to those. Even in the biggest companies, there are just dozens of meaningful projects.

A project has an ending date or deadline date — not a month or a quarter (those are 30 or 90 dates) but a single date — and everyone knows when the project releases or is complete.


When you work from mission to goals to projects, the most concrete expression of work on the team is the task. A task is the actual code to be deployed, whitepaper to be written, SEO tools that will be employed, launch event to hold, features that will be designed, and so on. While a few people might care deeply or contribute to the mission, and executives generally focus on goals, and managers live whole projects, everyone is invested in tasks.

Tasks are defined by those that will do the work and those same people (or person) will decide how long it takes. Every person contributing to a project might have dozens of tasks. Tasks should be from 1/2 to 2 days — less and the accounting is too painful and more and it is likely the work is not understood enough to reliably schedule.

There are two main benefits from spending the time to create a list of work items. First, the project overall becomes increasingly predictable which is important because of dependencies (such as front end and back end, or marketing activities). Second, when things aren’t going as well as planned there is a clear view of just how far off things are along with a pre-computed list of potential savings to be had by cutting different tasks. Whether it is Asana, Trello, Sheets, Jira or more the key is just having a system that goes beyond post-its around a monitor.

What is often overlooked is how much more effective everyone is when they know the why behind the what. Everyone will do better work if the worklist flows from specific projects which have goals that are measured in a particular way. Much of the work of this framework will prove to be making the connection from task all the way to mission.


One additional element that permeates all of your efforts is telemetry.

The most successful organizations are also fully instrumented organizations. Everything about code, customers, and overall engagement has telemetry.

Keeping an open mind and open eye to a whole variety of measures is super important. Just that as a matter of scale and operation, you cannot hold everyone accountable or change what is being done in response to every measure. If you’re learning something that concerns you then dig in. Maybe you’ll change your plans. But when you do need to change your plans you can do so in the context of an overall framework, not just single data points.

The combination of a framework and telemetry makes it possible to more globally maximize your return on investment. Telemetry alone risks a more local optimization. A framework by itself is just guessing.

It might seem like doing all this is just too much busy-work. There is an investment to be made. Most of the effort, however, will involve “editing” or “culling” from a list that was already too long or contained a lot of things not getting done. The most time intensive work is in creating the task list and is often the most disliked or difficult to make concrete. Everyone seems to have a feeling for what work needs to be done but resistance to putting it out there. The essence of an accountable organization is taking the team through this framework and making it part of every day work.

Just a small tool

There’s a payoff to all of this that is incredibly important. If you stop here all you’ve really done is document things going on. What is really important is that you assemble information so you can have a system in place to deal with change — unexpected failures in the market place, gain or loss of people on the team, new opportunity in the marketplace, or demands from a customer. Maintaining this information in a simple tool provides the product manager with that.

There’s always too much to do, so by definition we know we are not doing everything we can to be successful. Do we know if everything we are doing is essential to the success we hope to achieve?

Seems like a simple question. In practice this is an exceedingly difficult question to answer at any given time and even more difficult question to answer over time as conditions change. In fact, I might argue it is close to impossible and that the best measure of success is to view the efforts overall as a portfolio. Just like a portfolio, however, you need to spend time digging in to understand at a more granular level where you can do better. Failing to do so too often prevents us from ongoing evaluation of work to make sure it is really helping — if there is more work than can be done, the easy path is to just assume everything going on is helping. That’s not true though!

What is suggested below might be simplistic or you might believe you’re already doing all this and more. I’ve found that most projects, especially before product-market fit, can benefit from a more systematic view connecting work to projects and goals supporting the company mission.

My own experience is that this can be accomplished in a surprisingly straight-forward manner. Doing so illuminates the work of the team and provides a great tool for the shared and ongoing management of the team.

Let’s just assume we’re working with a spreadsheet, simply because we’re going to do some math with the data. Feel free of course to use any structured tool that supports features such as collaborative editing, group-by reports/pivot tables, filters, and some basic math. The specific tool isn’t important and should not be the source of the first debate on the team!

We tend to think of the task list as a literally listing of tasks such as Implement OAUTH, Add new chart type, Create sign-up response mail, etc. Simply getting all of these done can often be helpful enough. Most tasks lists will have a name associated with the work and I’d always encourage a single name, or said differently define the task so it is the work of one person. In addition, include a column for the amount of time the task will take (0.5–2 days). For good measure I would suggest also including the date to start/finish as that allows you to use the spreadsheet to understand the relative schedule.

Then take the extra step of making sure the Project is clear. Is it for the iOS App? Does it support the SEO campaign? Is this the Beta program? Adding this label should be some simple accounting as projects are by definition distinct and represent a single release or customer/market visible effort.

The next step is key which is to add one more column which is what goal the work supports. Is this task about something like retention or scalability, for example? Avoid the temptation to think something applies to many goals or rather force yourself to commit the work to supporting a single goal. Keep in mind you already know the goals so all you are doing here is picking from the 3–5 established goals, which in turn are associated with metrics.

With that in hand you have something that looks like the hypothetical below. You can see a connection between tasks, projects, and goals.


Keep this sheet up to date and you’re able to be ahead of the project. As simple as this seems it is just as often either overlooked or buried in too much detail to be broadly useful.

What can you do with this? There are several key sorts/filters that are enormously useful:

  • Any given person can look at their own work and know where they are and where it fits in
  • At any time, one can see how much of the time (resource) overall is going to support a given project or goal
  • Know which tasks are too far out, too big
  • Know which resources are over-constrained

And so on. This tool is the right level of complexity for projects from 10 to 5000 people in my experience. While many would love more such as dependency analysis or a task hierarchy, my experience is that is where the tool begins to overwhelm. When the tool overwhelms it isn’t used and so it doesn’t matter. (Quick note, when I first came to manage Microsoft Project I learned that the bulk of usage of the tool was not to track projects but to input a bunch of data at the start of a project just to come up with a nice-looking poster-sized Gantt chart printed out once at the project start.)

Managing projects is very difficult. While the bank account is draining and there’s a strong desire to keep moving is galactically more difficult. The fear of slowing everyone down with tools and processes is real and often justified. With so much riding on being efficient, effective, and focused it is worth investing a small amount in managing the work so as to make better decisions about what work to do and what happens when you get new information from the market.

— Steven Sinofsky (@stevesi)

Special thanks to @ProductHunt’s Ryan Hoover who took my suggested framework of Vision, Mission, Strategy, Tactics and made it much more approachable terminology. 🙌

Written by Steven Sinofsky

October 12, 2015 at 10:30 am

Posted in posts

Tagged with , ,

A Leader’s Guide To Deciding: What, When, and How To Decide

Science fiction (Star Trek) with officers sitting around a meeting table.Decision-making is one of the most difficult skills to master as a manager. A startup CEO literally sees a constant stream of decisions to be made: from hiring and firing, to Android or iOS, all the way to Lack or Billy. As the company grows to 10–20 people (usually mostly engineering) the bonds and shared experiences continue support decision-making at the micro-level. Once a team grows larger there is a need for management and delegation. While growth is a positive it also a stressful time for the company and founder/CEO.

Even for the tightest knit group with founding-team trust, the first decisions made without the CEO (or by simply giving a heads up to the CEO) are nail-biting moments for everyone. The closer the decision is to the core of the CEO experience the trickier. Deciding on UX changes or tweeting from the company account all test the ability for the CEO to delegate and the team to be delegated to.

As a company grows to having leaders and groups across different functions (heads of sales, marketing, eng, operations) the need to be systematic in delegating and deciding goes from optional to mandatory. Many founders resist this move. First founders rightfully care about everything — everything matters — and it is very likely he/she is in the best situation to make the best decision for the company. Second, founders that worked at a big company too often experienced dysfunctional decision-making and part of building a new company is to do better than that.

As a manager, I always found deciding to be both trivially easy and impossibly difficult. It is easy because like many, if you ask for an opinion from me you can get one. It is difficult because like many, the implications of sharing that opinion are not really known at the time.

For me, knowing what a decision really is about, understanding the full context of a decision, even just awareness of what is actually being decided are a few of the many challenges. Add to that all the management-speak about delegation and accountability and quickly I came to conclude I could justify any course of action. I could be anything from the center of a command-and-control decision making machine to a completely non-accountable, human-router-delegator of important choices in the name of building an empowered team.

I wrote this post in an effort to create a framework for how to think about decisions from the vantage point of a CEO/founder/exec as an organization grows beyond when the “hub and spoke” is the expected norm, and how to think about the good and crisis times when it comes to decision-making.

Deciding with Dysfunction

Making decisions is easy on paper, but a lot more difficult in practice. Worse, the more one practices the harder it is to make decisions simply because of knowing more and seeing potential downsides of just about everything. One might think experience would make things easier, and often it does, but it can slow down or even just prevent things from happening. When I was young, I could decide to drop in on a 15’ vertical half-pipe without hesitation. That was before I knew the downsides of injury (it was also before YouTube so all we had to look at for examples were photos)!

As the team grows, CEOs (and execs, depending on company size) face many challenges in getting things done or just picking the right things to do. One of the main factors is the increasing number of people involved in any choices. Deciding iOS or Android first will seem easy or “obvious” when resources are very tight and there’s no Android developer anyway.

Fast forward and consider the complexity when there is a newly hired sales leader who knows “works anywhere you do” will close deals, an engineering manager who still can’t hire an Android lead, a QA manager who is all about fragmentation complexity, or a newly hired BD lead who can choose between two partnerships but the better logo requires both iOS and Android. All of a sudden there’s no simple decision to be made and a lot of people contributing who feel their success hinges on going with their point of view. Play out over time the various potential outcomes and who is promoted, gets more responsibility, or is credited with success to see that this challenge is far more than just getting the right answer. That is normal.

As a result of people living this pattern over and over, many decision-making techniques and tools have been created. These codify a “decision making process”. In fact there is a whole Wikipedia article describing responsibility assignment matrix. These have a variety of acronyms like OARP, RACI, ARCI and more. The letters are various ways to define roles in important decisions such as reviewer/approver, recommends/consulted, responsible/accountable and more. These are tools designed to speed decision-making, clarify execution accountability, and ensure robust choices. Leaders figure out what to decide and assign various roles to participants and like magic decisions are made.

In my own experience these tools more often than not slow things down, make no one accountable, and all but guarantee compromises with which no one is satisfied. There are innumerable stories of how a well-intentioned taxonomy like the above can be used to grind work to a halt, push accountability around without establishing it, and turn a specific decision into a general battle over the meta. That’s unfortunate because making the right choices is incredibly important and having tools that add reliability and consistency to the effort would really help.

Rather than dissect a meta-process, I’d propose taking a step back and saying that the most important thing a CEO or executive must do is to keep the output and velocity of the team at the highest levels and focused on doing the right things. The first VP I worked for, way way back, hypothetically suggested “maybe a star could do the work of 3, or 5, or even 10 people” then he went on “the problem is we are doing work with 20, 40, or 50 people”. The implication of that math is clear. No matter how smart, hard-working, on top of things, or just amazing someone is, they need to work with other people and count on their work without actually doing it.

The core problem with a decision-making process starts with defining a decision and related inputs. Almost never is there all the information needed or wanted to make a choice and wait long enough then chances are context and options have changed enough to make the decision framing all wrong. So all that was really accomplished was slow everything down by simply by trying to define the decision to be made and what inputs were needed (apparently this also holds for the Federal Reserve Bank).

We know that almost nothing is made up of a single decision at a single point in time. Ask yourself how many discussions or meetings you had where you thought there was a yes/no, or a choice to be made, and after running over time the only decision was to wait, learn more, or come up with new options? It is only long after clear success or failure does the historic narrative turn into the “big decision” (and associated drama).

The essence of an agile organization is figuring out how to make fast progress against larger goals, learning and adjusting along the way. In that context, many at the company make decisions every day.

Stepping Up For Growth

With so much happening every day, rhythm is the biggest enabler of agility. If a team operates in a Flow, then everyone can do their best work. We all know what it is like to groove. We also know what it is like to have that groove interrupted by questioning the choices made or pausing to have choices validated, reconsidered, or tweaked.

Trying to get ahead of decisions sounds great. This quickly turns into trying to know what isn’t known and worse to prepare for it. Finding a way to codify the set of problems that will trigger a review or joint decision turns into a meta-planning exercise trying to agree on potential challenges.

In my experience, the real challenge is in trying to define decisions, isolate important ones, and then figure out the stakeholders for that once instance. Decisions are everywhere. Deciders are all over the place. Every identifiable decision is made up of many other choices, constraints, and stakeholders.

The following is my own idealization of the role a CEO or exec can play in decisions. Instead of kicking off a process for a single decision, spend the energy up front to decide what and how the CEO will work. Thinking this way allows for a variety of approaches for getting involved, delegating, or empowering. It avoids the complexities of figuring out what it is that is actually being decided and hairsplitting accountabilities among individuals. It introduces agility into a process rather than rigidity.

My own experience led me to believe that before I decided something that was brought to me, I had to have an idea of what role I was playing in the process. It is easy to be a boss and assume people need your wisdom, advice, or context. It can be tricky to know if you are really adding that, affirming the choices of those who work for you, randomizing them, or simply doing their job for them.

With that experience, my view is that before deciding something a CEO or exec should be clear how he/she contributes to a project or work, using one of the following:

  • Initiator. Kicking off new projects.
  • Connector. Connecting people to others so the work gets better.
  • Amplifier. Amplifying the things that are working well or not so there is awareness of success and learning.
  • Editor. Fixing or changing things while they are being done.

Let’s look at each of these in a little more detail.


As a practical matter, assuming the organization is running at > 100% capacity then there’s a finite amount of initiating that can be done. Almost everything kicked off at the exec level looks like the strategy, new projects, new organization, or the prioritization of work. Creating or seizing new opportunities from the leadership vantage point is precisely it means to be the initiator.

  • Examples: Kicking off something entirely new (hiring process, first sales deck, new product release, opening a new position. Deciding to make a big bet on a new technology, platform. Starting a new strategic or transformative initiative.
  • Tools: Write it down in a way that someone joining the project later can quickly get up to speed. I believe writing is thinking, so taking the time to gain clarity on what to do and what success looks like only helps. Pro tip: Drafts circulated to a small set of key people, but quickly along with seeking and acting on feedback can be very valuable.
  • Granularity: Almost always this will be fairly coarse like “launch day” or “new product” but can scale all the way down to being the specific such as “add this feature”, “create a partnership”, “publish APIs”.
  • Time: When operating in a rhythm (product cycles, launches, adding new leads) initiating becomes a key part of team rhythm. About 10% of overall work is initiating new work or projects.
  • Mindset. The most important work of an exec is in kicking off a new project so put the most effort into this work product. Initiating is the only time an exec does the work of an individual contributor.


Most all decision-making challenges happen across domains. Rarely does a solid engineering leader pick the wrong toolset. Rather the toolset is wrong because the full scope of the challenge was not known. Anything crossing functional lines requires a connection. The exec is in a unique position to be constantly connecting functions and work. Helping people to know more about what is going on with others on the team while recognizing this almost never happens by chance.

  • Examples: There are classic examples across functional lines such as connecting sales and product. Many of the most interesting examples are the non-traditional ones, which can help people to gain more experience such as connecting engineering to customers. Facilitated connections rather than simple introductions afford the chance to see how parties use the connection and to drive an agenda consistent with a rhythm.
  • Tools: Presence, listening and talking have no substitutes. Even with everyone being online and available, don’t assume everyone or the right people will read everything. With any size team, the amount of “FYI” or automated information will quickly overwhelm even the most diligent. Rather than believing status reports and scorecards will connect, execs must focus on making specific connecting efforts with clear intentions to move things along. Most work has natural points where checking in makes sense. Rather than relying on ad hoc connections, use a structured approach to surface the right issues.
  • Granularity: The reason connecting is fun is because when it not randomizing or micro-managing, but simply sharing and getting head of potential problems. Connecting peers together is a service to the team.
  • Time: Spending more than half, perhaps 60%, of the time connecting is routine among CEOs and execs. A useful way to spend time is on structured, periodic checkpoints that connect the status of the current work to the start of the project. Pro tip: Most every interaction can serve as a chance to connect one part of the team to another or a CEO’s external context to what is going on internally while also using the opportunity to demonstrate listening while not trying to solve everything along the way.
  • Mindset. Connecting is the field work of the exec. Execs should be thinking about what to connect almost all of the time. Connecting skillfully is a force multiplier.


The CEO or exec soapbox is a super valuable tool. Within a company there are not only good things worth letting everyone know about, but lessons learned that could be shared. Since it is a given that not everything can be thought through in advance, seeing and amplifying the creative ideas or great execution seen along the way can be seen as a proxy for initiating new things. When a CEO stands up in front of the team and celebrates success or learning it just matters more.

  • Examples: The best example is to amplify the good work of the team or to turn failure into a lesson. Amplifying the good work of competitors, sales wins, or collaboration across functions gives leaders a chance to call our efforts that cross many parts of the company.
  • Tools: The team meeting is the most valuable forum for amplifying and often supporting this with something in writing (or a t-shirt or sticker!) works best. Amplifying work is also related to connecting work and often they are two sides of the same coin. The most compelling efforts to amplify are supported by great stories — when taking the time to amplify something, do so with the whole story and the background that makes it worth amplifying. It is one thing to tell people something important, but another to describe why it is important.
  • Granularity: Amplify things that apply to many people on the team but do so with a frequency that maintains meaning and impact. Pro tip: When celebrating success, execs should be sure to give the right credit to the right people.
  • Time: Execs have a unique ability to amplify success, which in turn makes this a high value effort so it is worth spending 10% of time.
  • Mindset. It is fair to view amplifying as a bit of a tax. As is often said in management, “what’s worth saying is worth repeating”. Ronald Reagan was famous for not veering off important messages because he believed even though it was old news for the press corp, it was new to those in the live audience.


In a big company, people just wish execs would go away and let them do their jobs. In a new startup, execs are doing the work (i.e. coding, selling specific accounts, designing the UX). Everywhere else many people are doing the work and the exec is figuring out when to contribute. Somewhere between “swoop and poop” and “micro-managing” is the role of contributing editor. I use the term “editor” specifically because this is about changing (or improving) the work created by others. Editing is the right of a boss, but also a privilege in a team made up of smart and creative people. Everything about editing is in how it is done. Poorly done, editing makes people feel bad and never generates the best work (except for Steve Jobs as many like to say). Done well, and editing makes everyone feel better about the collective effort.

  • Examples: Redlining a document, drilling into a design review, redoing a positioning framework, creating an outline for a blog post or release, designing the 2×2 competitive framework are all examples of editing.
  • Tools: The most important “tool” to use when editing is to do so in-person. The vast majority of editing feedback comes across as negative and critical. While there is always enough bad work to go around, finding ways to be constructive is always worthwhile. For better or worse, editing without verbal context or worse just being critical over email almost always makes things worse.
  • Granularity: Chances are the granularity of editorial input is very fine-grained. The question is not really whether to edit or not, but how many times the same thing (even for the same person) is edited. Repetition means there’s a systematic problem with communication or the people doing the work.
  • Time: Editing is a big time commitment, but not the biggest. It also comes in fits and starts. More important than time is timing. The later in the process or the closer to the deadline the higher “cost” being an editor has. Overall about 20% of exec work is editing.
  • Mindset. This is the comfort zone for every exec, especially when it is the type of work he/she did individually. The important thing is for the exec to really know the importance of the changes.

With a framework or roles like this, there is clarity in how an exec is working with the team and how work is started, iterated, and completed. I would also encourage using this framework by managers at all levels in a company. One changes the time devoted to each type of interaction.

Diving In For Saves

At this point, you probably think this all sounds well and good, but what about when things are going sideways?

When things go sideways none of this matters.

In fact, none of this really matters if the company are such an early stage that there are no more than a couple of dozen people. It also doesn’t matter if there is not yet product-market fit.

In Ben Horowitz’s Hard Thing About Hard Things, he describes the differences between a “peacetime” and a “wartime” CEO styles (specific post is here). I love his framing of decisions that pose existential questions for the company. That is a fantastic way to know when there really aren’t decision making processes other than whatever the CEO wants to do to survive to another day. Rarely are exec level choices existential at the same level, which is worth noting.

In a startup, the wartime CEO pretty much describes things until there is a solid revenue and profit stream coming from a product that works for the market. Most everything amounts to an existential choice or decision.

In an organization that is more or less working, this is a more subtle challenge. At some point few decisions are truly existential, though it turns out it is tough to know this is the case while everything is happening.

There was a recent Facebook thread among a few of the original leaders of an old Microsoft product. From the outside, most people see only the victory and to read their comments one would think it was all a cakewalk. From inside the team, every day felt existential and every choice seemed to be about the success or failure of the whole. This is the norm at big companies and explains the origin of those questionable “decision support tools”.

This all boils down to product-market fit and deciding when in fact that state was achieved. Before that time, everything is existential. After that time, most decisions are relatively minor. Unfortunately, knowing this dividing line isn’t so straightforward and the clouds of disruption always loom on the horizon. This is the fog of war in a big organization.
Operating all the time in crisis mode or thinking every choice is existential is just not sustainable as a company or leader. As fun as it seems, a whole yoga practice upside down is not a good idea.

As a company scales, the long tail of choices and decisions feels existential from within even if they aren’t. There’s no magic answer as to when one is at war or peace, even in hindsight. My view is that a CEO can decide the one thing no one else can, which is to decide things using a poorly defined process. Just keep in mind that even the most successful CEOs and execs can eventually use up that luxury and either adapt how they work or watch people leave the company.

The original generals, in the military, have evolved their thinking and modern warfare now employs the notion of commander intent as a leadership practice for just these reasons (and more). If you are interested in how the largest and most process-oriented organizations evolve, the report linked to is fascinating.

With the most robust product market fit, there will be existential moments demanding wartime decisions: a major security breach, service outage, failed sale, or losing key members of the team. Don’t ever be worried about deciding in the most top-down, non-empowered, toe-stepping manner when facing a true crisis. That’s what leadership is all about. Using the framework above, a crisis situation just demands a great deal more editorial actions.

Making decisions is something that at first comes naturally, even easily, and then as a company grows the complexity creeps up on CEOs and execs. Some of this is because with experience comes awareness of all the things that can go wrong. Most comes from the challenges of scale and decisions of when and how to let go of some things. Decision making challenges come when an unlimited amount of passion meets a finite amount of time. Taking on this challenge without introducing a mindless bureaucracy is an opportunity for a growing company.

— Steven Sinofsky (@stevesi)

Note: Also sim-published this on @medium.

Written by Steven Sinofsky

September 10, 2015 at 10:59 am

Posted in posts

Tagged with , ,

Tools for a More Inclusive Workplace

Everyone is interested in imInclusive teamproving 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:

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.

Steven Sinofsky (@stevesi)

Written by Steven Sinofsky

August 21, 2015 at 3:00 pm

Posted in posts

Tagged with , ,

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.

PressureOne 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!

Written by Steven Sinofsky

August 17, 2015 at 9:00 pm

Posted in onestrategy, posts

Tagged with ,

Privacy and Security: Less Rhetoric and More Product

malware advertisement 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.

nytimes.com web page privacy policy

nytimes.com license agreement showing lack of information about linked sites.

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.

—Steven Sinofsky (@stevesi)

# # # # #

Written by Steven Sinofsky

June 7, 2015 at 4:30 pm

Posted in posts

Tagged with , , ,

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.

Steven Sinofsky (@stevesi)

Written by Steven Sinofsky

May 23, 2015 at 11:00 am

A Product Person’s Perspective on Enterprise Selling

An architectural diagram for 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.


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.

Steven Sinofsky (@stevesi)

Written by Steven Sinofsky

May 22, 2015 at 10:00 am

Posted in a16z

Tagged with , , ,

%d bloggers like this: