Management

Delivering Change

When you think of great products, what do you think of? Products that have altered the way office jobs are done (excel, outlook, DropBox), or changed the way we interface with computers and technology (iPhone). Hearing from the VP of Product at Change.org recently was an opportunity to hear from the head of one of the most impactful products present in the market today, as evidenced by the impact on politics around the

BlogPostYellowShirt

French president responding to Change.org petition

globe. This presentation concerned the organizational tools that the team at Change.org used which led to the successful creation of an entirely new product line, circa 2011, to support a major shift in Change.org‘s business model.

The problem facing Change.org was that the revenue source had been a pure B2B model, which was no longer viable. Meaning that the grass roots petition platform that exists today did not exist. It became clear to the leadership of the organization that the business model was no longer feasible and had to be changed due to external market factors. Nick (VP of Product) led this effort from the product side and by using a few different concepts and methodologies successfully led the team to create the product line which made Change.org what it is today.

Problems Faced

The main internal problems that the company faced in developing an entirely new product line were the following:

  1. Speed of Delivery: Slow progress towards product completion
  2. Alignment: Getting the organization to work in the same direction
  3. Focus: Inability to make meaningful progress towards the goals that have been set

In order to confront this problem, there were a few different tools that were utilized by the team at Change.org that stood out to me. The team  utilized some of the obvious efficiency levers, like automating tasks, but the strategic/organizational decisions are the most interesting.

Avalanche

As a previous product owner, one of the main frustrations regularly encountered was the inability to make forward progress due to all of the work needed to “keep the lights on” as it’s commonly phrased. Change.org made the conscious decision to focus solely on creating new features for a limited and focused period of time. That means no fixing of features that break (I assume other than P1’s). No devops working performance tuning. The whole organization fully focused on features.

One of the anecdotes shared that stuck with me was when it was mentioned that two college hires ended up working on a feature with the CTO. When you have an entire organization aligned behind a single goal, the ability to have people naturally move across, up, and down traditional power structures to achieve that goal seems to be a huge gain in creating innovative solutions. In addition to having more deliveries towards that single goal, the fact of the matter is that also comes the ability to see the pain points and what other teams are dealing with/issues they have.

Once the avalanche was done, Nick mentioned how devops had a much better understanding of the issues facing the application development team due to the fact that these devops developers had been doing feature work on the application. With this understanding they were then able to take these learnings and implement solutions that were able to make big impacts within the organization.

Shots on Goal

Anyone who has worked in an agile environment should be aware of this, but the affect that this had in the organization is worth mentioning. Specifically how deliberately this discussion was had with leadership. What Nick realized is that they were entering an entirely new market. Knowing this, he knew that it was unlikely that the organization would be able to accurately predict what features the new consumers would adopt in their product line without releasing many features and finding out what worked.

To that point, Nick organized his team to focus on flexing their speed muscle, as opposed to quality. Why deliver 10 perfect features when you could deliver 100 working features and have a much higher chance that the organization will strike gold? That strategy led to multiple success in the new product line, and an ability to conduct and test experiments faster than they thought possible under the previous paradigm which tried to achieve both speed and quality. When a team is focused on an immense effort, making demonstrable progress is usually one of the hardest/most difficult things. By focusing on speed, much faster feedback loops were enabled, with some of these features contributing to more than 20% revenue growth from the new product line.

OKR

Objective and Key Results methodology. Google used it. Intel used it, and countless other organizations. It’s not reasonable to think that an organization can deliver an entirely new product line and business model without complete organizational focus. Using OKRs Change.org was able to create a clear focus. As a result the teams were able to deliver on what is meaningful and impacts the bottom line, as opposed to working towards multiple objectives and goals that cause people to tug and pull against one another.

Blog2-measurewhatmatters

Great book which provides a history and overview of OKRs

Working in multiple organizations, I’ve noticed that people don’t know what to do when their are too many goals. Having the ability to walk into a room and point to a single goal means that the organization is more easily able to coordinate and implement. When there is no clear goal unnecessary road blocks, and fiefdoms tend to spring up and lead to the organization pulling in different directions getting in front of the accomplishment of organizational goals.

Operating teams using the above three strategies worked for Change.org. Using some of these strategies has worked for other large and small organizations, and from what I’ve seen thus far in my career, could be used in many other organizations to transform the way products are delivered and impact the bottom line.

What Should Documentation Be?

The problems Business Intelligence organizations solve in organizations are generally the same. Pull some data out of somewhere, synthesize the data, analyze it, then create a picture of what is happening, what is going to happen, or what has happened. Working in small and large organizations, I’ve had the pleasure of seeing a variety of different processes used to deliver these insights. These range from the overbearing, and associated documentation that crush people’s productivity, to the lightweight that creates quicksand beneath teams feet through the lack of knowledge transfer.

Seeing the overbearing and the extremely light weight, there’s one conclusion I’ve arrived at concerning documentation…

Document as Little as Possible

 

documentation_joke

Relevant literature

Don’t commit time to things that aren’t creating revenue or helping the business. Looking at IT projects, there is no doubt that the more documentation that there is, the less value there is. The perfect example came about when having a beer with a former co-worker.

 

It was brought up that the process at the company we both previously worked at had documentation that took longer to create then coding, testing, and implementing the change. Additionally, this painstakingly crafted documentation that the engineer had to spend time tracking down information for didn’t result in documents that would be useful to the team doing the work going forward. The process decreed that you must document X, Y, and Z in order to deploy the change/implementation so that’s what was done. The fundamental truth is that the “…benefit of having documentation must be greater than the cost of creating and maintaining it.”

Some people believe in the exact opposite of over documentation. Nothing should be documented. The code/implementation should speak for itself. This may work when you have a small size IT application the will always be managed by the same group of individuals (which likely won’t happen). Once you reach an application spanning multiple servers, teams, and databases the expectation for the code/implementation to “speak for itself” in a timely manner to those who have to report and get analytics out is unreasonable.

So, what’s being proposed in this rant? The only useful documentation that I’ve seen documents the “Why” and the “How”. Everything else doesn’t create value for the organization, as the cost to maintain and develop the documentation is too high.

Why

Creating a BI Product entails connecting the business process to an application(s) or database(s). Depending on the environment that you’re working in, Inmon, Kimball, or something else entirely, you need to know the answer to why things in your system exist. The “Why” is important not only from a high leadership level, but also at a low technical implementation level. The “Why” statement done at the low level helps to ensure that a team is using previously created tools and implementations as designed. And if a change is made that goes against the original “Why”, it is intentional and by design.

As an example, working on the Vehicle Profitability by VIN project, the Data Architect created both Inmon (3-NF) and Kimball (dimensional reporting) structures on the project. The “Why” was made extremely apparent through documentation, so the teams knew how to use the current implementation to achieve their goal in the best way possible.

Are you importing new invoice data? That should go into the wholesale invoice structure so that it flows up in the existing fact that contains the revenue information for vehicles which our reports feed from. Why? Because we want a single source of truth for vehicle revenue.

When documentation providing the “Why” for technical implementations exists, it makes adding on and changing the existing processes and assets easier. As opposed to re-inventing the wheel over and over.

How

Payment-Data-Flow-Diagram

basic data flow diagram

So after we know why something exists, the other piece that is useful for documentation is the “How”. The “How” shouldn’t be step by step instructions, it should function like a high level map. Data Flow Diagrams are a great example of “How” documentation that I’ve found useful for Business Intelligence products. Armed with the Data Flow Diagram and the “Why” of the design, team members who need to report on, extend, maintain, or refactor a system will be able to make informed decisions.

 

 

Make It Useful

At the end of the day, documentation gets in the way of creating code/analysis/direct business value. So the argument for spending time creating documentation is hard to make when someone hasn’t experienced the pains associated with lack of documentation. Lack of architecture that makes sense, misreported numbers, time wasted building processes that do exactly what existing processes already do.

Without documentation, maintaining and using a system or process as intended is impossible. With documentation that is accessible, searchable, and focuses on the “How” and “Why”, organizations can make smart and informed decisions of where to spend time, how to tweak things, and how to get value from their assets.

 

Inspiration vs Manipulation

A few weeks ago I was lent a copy of the book Start with Why. The ideas around the use of manipulation vs inspiration to change human behavior is one of the ideas that struck a chord with me thus far. Looking at companies today, there is a clear differentiation in the way that organizations position themselves based upon where they fall with when using manipulation vs inspiration.

Inspiration

These are the companies that get the best employees, deliver innovative solutions, and much of the time have higher margins and growth compared to competitors. How is this achieved? You guessed it. They have a great and inspiring vision of why they do what they do.

spacex mission.PNG

This vision and end goal above is lofty, and certainly something the people (especially rocket designers) can aspire to. Having such a vision for where the company is headed has apparently worked to Spacex’s advantage. Spacex has managed to steal significant market share from the much older Arianespace. There there must be something behind Spacex’s success.

commercial_launchers_web_1.12.151-879x485

The focus on a lofty vision of “why” an organization does what is does not only drives profits, but also clear and concise decision making and motivations for all who are involved with the company. Driving behavior towards a goal that is inspiring and internally motivated is much more effective in the long-term  compared to manipulations.

Manipulation

Price, promotions, fear, aspirations. These are the tactics that are potential changers of human behavior. When making use of these strategies, a company has most likely lost sense of why it exists. The reason for this? When a company is offering to cut price, or market to customer aspirations, there is no longer an internal motivating factor that drives the company. The company compass for decision making has been lost.

The great (or terrible depending on your perspective) example of this is General Motor’s use of promotions to drive sales. In the 1990’s General Motors, along with other US auto manufacturers relied on offering of sales incentives to retain market share when faced by an onslaught of foreign automakers. By taking this route, the US automakers effectively weakened their brands. This may have allowed the automakers to retain higher market share short-term, but it obviously didn’t help the long-term growth and profitability of the company.

Manipulations create addictions for companies that may create some short-term value, but it is at the expense of harming the organization in the long-term. The more fear, promotions, prices cuts, and aspirations a company uses to sell products the cheaper the brand perception will be.

Bottom line, knowing why a company exists provides in internal locus of control which has been proven to be a motivating force compared to the use of manipulations. There’s a reason that Apple customer’s pay more than a 20% premium compared to competitor products, and it’s due to knowing why.