Thoughts on Enterprise Software

Companies Lie To Themselves

Posted by | Thoughts on Enterprise Software | No Comments

I have a bone to pick. Having worked for a decent amount of enterprise focused software companies now, I’ve determined something that truly bothers me. I think this may be very specific to software (perhaps not though!).

Companies are constantly lying to themselves – and it’s making them worse.

I mean this in particular towards the sales and product teams. I understand why they do it but I disagree with the entire premise. Here’s how it goes.

We’re in a competitive deal. There’s multiple other potential vendor plays. It’s the final stages of the deal and BAM! The champion delivers the email no sales person wants to hear: “We went with another solution”. The org starts freaking out, tries to save it, but ultimately can’t. We send in competitive research to do a post-mortem and figure out what happened. Then, we send out an email to the broader organization, generally saying something like the following:

  • “They weren’t the right market fit size for us”
  • “They didn’t have enough budget and we were too expensive for them”
  • “They aren’t mature enough yet for our solution”

Here’s what I don’t like about the above: none of it comes back on the company. It often times feels like we pass the buck on why things didn’t go well. While statements may be true, there is significant product development feedback in each of those quotes.

In a little bit of a rant, what I hate about it is it creates a culture of “us vs. the customer”. Teams read through the emails and don’t view it from the lens of how we, as a company, can do better. Where we can improve on in the product, whether our pricing structure makes sense, whether our product messaging is hitting the right audience, whether it’s easy enough for users to use our product, and so on. We say things like “well, guess that customer is going to miss out on how awesome we are”.

It’s that bravado that drives me nuts. Part of building software is the relentless effort to improve the offering and capture the largest market share possible. Now, I get that we don’t always want to do that. Sometimes we really don’t want to sell to SMBs because they have budget constraints and really aren’t mature enough. But what I’m trying to hammer home is that the culture of what we do with that information is what drives me nuts.

Extremely high performing organizations look at every loss as a stab wound. They triage it and figure out what moves they made that exposed them. They believe they are at war and feel that making a mistake jeopardizes their god-given mission. They weaponize the loss and turn it into energy to improve.

Bad performing organizations love the smell of their own shit and believe they’re building something akin to a cult where the customers are “lucky to have us”.

Don’t be like the bad performing organizations. Don’t be scared of worrying your employees by sharing what we need to change or improve on. Create best next action items from the loss on how to improve. Instead of building a culture of shelter from that loss, build a culture of weaponizing losses in to gains.

Visualizing High Performing Enterprises

Posted by | Thoughts on Enterprise Software | No Comments

In my previous posts, I talked through some of the interesting findings from our research at Workfront around analyzing 600M hours work getting performed across tons of different verticals. We found some interesting stats like the avg. number of people on a project is 5.4 or that 76% of work created and completed comes from a process.

We took it another step further to better understand what it looks like to be a high performing enterprise. Our mission at Workfront is to help companies operate better and to make it so that people know their work matters. To do this, we need to see what it looks like to be a high performer. We know what the numbers look like but that only took into account a couple of variables.

Our work primarily focused on how we can accurately predict whether a project would complete on time. We extracted a handful of features that we had high confidence on, created a training data set, then ran the numbers through an exploratory machine learning pipeline. This included models such as neural nets and SVMs which helped us figure out which model could consistently deliver us predictable completion dates. It’s worth noting that we had to do a lot of data normalization and transformations in order to make the numbers work out. For example, it’s hard to visualize a process that takes only 5 days to complete versus a process that takes 500 days.

What we found was like any data exploration effort: the data tells a compelling and actionable story. We found that a best-fit line that was equal and the “x” and “y” axis through our visualization represents a fairly optimal work process. When the line skewed higher on the y-axis and less on the x-axis, companies we’re dramatically underestimating the effort required to get work done in their processes. Conversely, if the line skewed lower on the “y” and higher on the “x”, it means that the organization was dramatically overestimating the complexity of their work and that they could take on more work should the learn to optimize their process.

1 – This means that users had high accuracy of their plan vs. actual minutes and our model was able to accurately predict project duration. This is the ideal state.

2 – This means that users underestimate how long projects will take. They take on too much work, rebase their delivery dates, or have poor scoping practices. This is a non-optimization process.

3 – This means that users over estimate work efforts and have not gone back to optimize their processes. The org “looks” busy but can actually take on a lot more work. This is a non-optimizated process.

Below are a couple of high performing and predictable organizations.

When we visualize organization that we can readily predict their delivery dates, we get an interesting pattern. The tighter the scatter plot, the more consistent and predictable the organization. Curiously but not necessarily surprising, we also found that these organizations completed an order of magnitude more work than organizations with a wider scatter plot.

Don’t you love it when you find little gems like that in your data? 😉

Below are a couple of low performing and unpredictable organizations.

You can easily see that the data points have a much wider distribution which means that we weren’t able to get accurate project completion date predictions. It’s also easy to see that there is a significant less amount of work items being completed.

Now, one flaw with saying that the amount of work an organization can complete due to a process is that not all work is equal in complexity and size. That said, I would still say that this is a good leading indicator that there is a decent amount of truth that shows these work items are close in size. We found that the top 10% of processes that generated 80% of the work had an average of 12 tasks per process. Qualitatively, we also know that many organizations use their processes for fairly similar use cases (Eg. marketing campaign, product prototype, etc.).

We’re doing a lot of fun data explorations such as this in order to better understand user behavior and how to contour our software to augment users to be more efficient. It’s a journey through the data that requires a lot of time and a love of the labor, but we continue to find fascinating aspects that drive our product roadmap into new areas.

Data from Analyzing 600M Hours of Work

Posted by | Thoughts on Enterprise Software | No Comments

Part of my job blends the qualitative and quantitative analysis of customer behavior. Either route can kick start a hypothesis that sends me down a rabbit hole. I’m a data nerd and love diving deep into the numbers so this most recent endeavor has been fascinating to me.

It all started with a theory that my colleague and I had: people don’t manage projects, they manage process. It’s a simple statement but is hugely profound when it comes to organizational change. Managing projects implies managing the activities within a specific timeframe. Managing process implies managing the deliverables and outcomes that run through the process, unblocking efforts to produce outcomes.

We spent a lot of time onsite with some of our largest customers and started to hear similar ways of them bending our system. You know you’re onto a fundamental shift in behavior when your users rigorously use your product for something that you didn’t intend for them to do. These customers use highly repeatable processes to get a significant amount of their work done. They leverage process because it helps with optimization since you have clear stage gates where blockers can be tackled.

We also heard this from industry analysts too. The largest companies in the world are shifting away from a typical PMO model to a more agile (little “a”) process driven model where the key output is deliverables that they measure a change in outcome against (eg. Did this deliverable drive a difference in outcomes). These enterprises are having to get really good at this because they are getting disrupted by smaller companies who can blitz their strategy better than they can.

We found this discovery fascinating and decided to dive deep into the data. Our system has tracked over 600 million hours worth of work, so we have a good sized data set that we can rely on for significance. Here’s what we found.

75% of all the work in our system comes from repeatable processes. Specifically, for our enterprise customers, that number is higher at around 80% on average. There are certain industries (eg. creative, finance, legal) that have even higher numbers at 90%+ of their work being process driven. The average number of unique processes an enterprise has is ~100 (ones with quantifiable usage).

The average process has 12 steps. Even more than that is that over 77% of the work performed in these enterprises comes from just 10 processes or less. I’ll note that these aren’t just small companies either. These are your Fortune 500s with thousands and thousands of users in our system on a daily and weekly basis. This last fact just blew my mind. You’re telling me that 77% of the work being performed (on paper) comes from just 10 or fewer processes? Crazy.

Some other interesting heuristics we found were around working behaviors. SMBs typically have activity lasting between 7am and 4pm. Enterprises between 8am and 6pm. Government between 9am and 4pm. The highest levels of activity are Friday (closing work out) and Sunday (prepping work for the week).

These were fun tidbits of data that we discovered through the process. For those in the software world, it would make sense that project management is dying. Our world doesn’t really recognize that method of work. However, for the rest of the world, this is a huge shift that has been caused by the disruption of software. They’re taking a queue from the software world on speed and agility, trying to inject that into their own organization.

This is an active journey so I suspect that I’ll have many more data points that will come to play. I’ll make sure to update them here as we dive deeper.