♪♪
-Technical people, I hate to tell you,
but you are own worst enemy, or at least you can be.
Let's talk about why that is.
I think one of the things I've observed
in talking to lots of people
is technical folks get very frustrated
when, say, a product manager says,
"Can't we go faster?" or, "Why can't we do this faster?"
It tends to generate frustrations
when people question your decisions,
and part of being in the budget game
is there's a lot of that that goes on,
and it can oftentimes be pretty frustrating.
One of the things that worth thinking about though
is doing a little self-reflection.
What are your biases?
What do you bring to the table?
What is it that's frustrating you?
And also kind of putting yourself
in other people's shoes to understand
that there's more to this product or project or company
that you're in than just the technical piece,
just the bits that you're responsible for.
And success oftentimes really does require
this diverse set of opinions to come together
and actually respect each other for what the strengths
are that each person can bring to the table.
I wanted to spend a few minutes talking about that.
Let's look at it from a couple of different perspectives,
happy to share some of my past failings in this department
as part of just kind of understanding
what it can be like,
so the first thing I think is important
is this notion of an MVP, right?
You want that minimum viable product.
How do I get there?
What do I decide that that looks like?
How many features do I need to have?
And pieces of that will involve pricing and packaging
and other components that are really the project management
and the interface-to-customers teams' responsibility
to sort through, but all of them come together
to making an actual product that is a real MVP.
It is minimum. It is viable,
and it is a product you can ship to customers
and then iterate it, of course.
The whole point is to be able to iterate quickly
and add more functionality, so to get to that point,
I think one of the challenges a lot of folks face is,
they don't truly understand who their customer is.
Sometimes they don't know if the person they're talking to
is the decision maker, the user of the product,
an advocate for the product, or maybe they're not.
Maybe they're actually in a different camp,
and they don't think the product belongs in their ecosystem,
so understanding who you're building for...
Is this going to be for developers,
in which case you've got some great conversations you can go
and have as a developer with those developers
to understand what they're looking for
and do some pretty quick tweaks and changes
and learn a lot about the usage patterns?
Or is it more of a consumer-style thing
that you're trying to build?
In which case, you've got this layer of this abstraction,
this interface to the user that oftentimes need to be
extremely simplified from the underlying technology
to be as useful as it can.
Another area that I've spent time in is enterprise.
You're targeting an enterprise IT shop,
and with that comes a whole host of requirements
that oftentimes are sort of tangential
to what you're trying to solve for,
and they have a lot to do with integrations
with tooling or integrations with security infrastructure
that may exist at the company,
reporting and things of that nature,
and they can add a ton of time to the project work,
but you need to understand what's required,
and those oftentimes are pieces that are required
if you're going to sell into enterprise IT.
So to get this mapping done,
you really do need a partnership.
You need to partner with people who can go
and spend a lot of time digging into the customer base,
a lot of time looking at what else is available,
spending time figuring out how to price something.
Is it going to be a subscription?
Is it going to be a buy it and done?
Is there a roadmap you can build that continues to evolve
and provide more and more features
and functions to the user base that you're trying to serve?
And all of these things, they take time,
and they take effort,
and they take collaboration, right?
You need to respect the views of the people coming in,
and like I said, it can be really hard
when the view that you always hear,
the thing that first pops up in the meeting is,
"Can't we go faster?
Like, why is this taking so long to build?"
But in reality, there's something behind that,
and the something behind that is,
"Can we get this first idea in the market
and see if it makes sense to people?
Can we test it with users?"
So I think there's a lot to be said
for taking that giant step back
and trying to analyze where everybody else is coming from
before you react and kind of put yourself into a mode
where you get a better sense of,
"What are we all solving for as a group?"
I certainly remember in the computer-science classes,
everybody dreaded the group project, right,
because you always knew that some turkey would be at the bar,
not working on their code, or somebody would just drop,
you know, out of sight, and you wouldn't see them,
and their piece wouldn't get done,
and nobody wanted to do group projects because of that,
and the reality is, in the real world,
everything is basically a group project.
And so learning to work with other people and understand
where they're coming from is an incredibly important part
of being successful.
I think if you look at quality and say,
"Is it about quality? Are they pushing me not to finish?"
And the answer should be no, right?
You want quality.
You don't want to ship something that doesn't work.
It's really about bells and whistles.
Do I need all these extra pieces in there?
One of the classic things is,
you know, premature optimization.
People build something to scale to a level they're nowhere near,
and the time you take to do that is time not spent in the market
testing your ideas with end users.
So there's a lot of trade-offs that you need to think through
and really work at,
and it really does help to have partners
that you can have these discussions with and understand
what those trade-offs look like
to make the best possible group decision.
Let's talk about a couple examples.
I can think of a couple that come to mind for me personally.
One was, I spent quite a bit on
in the hardware-monitoring space,
and you would think software monitoring,
but we actually built hardware-based
monitoring for software, so it was cool.
The technology was amazing.
We could do things nobody else could do.
We actually had FPGAs.
They could count transactions on wires at line-rate speeds.
We were pretty unstoppable
when it came to solving the hardest possible problems
that any customer could ever face,
and we saw a couple of challenges in that.
I think one is the idea of buying hardware
to watch your software operate
is certainly not super appearing.
It's very expensive.
We were targeting enterprise, right, enterprise IT space,
so we knew that we had sort of a limiter on scope or scale,
but we also recognized later
that a whole lot of innovative things
were happening in the monitoring space
that were very much focused on, "Eh, it's good enough."
Like, "I can get you something that gives you an answer
to some of your questions but certainly not all of them,"
and we were very focused on all.
We wanted to be able to get to the nanosecond resolution.
We wanted to be able to guarantee, effectively,
that if you were having problems in a large complicated network
that we could spot that problem and solve it for you,
and I think that it was a very appealing thing
for the Fortune 100,
which was the sort of meat of our customer base,
many of whom bought, but the reality was,
we couldn't scale that up to a broader audience base
that wasn't willing to deploy hardware,
that couldn't understand the complex nature
of the information that we provided back,
and ultimately, you know, there were all these companies
coming on the scene that were being hugely successful,
very, very rapid growth,
and that growth was driven by simple,
not always super accurate solutions
that didn't worry about things like,
"Am I going to be completely accurate
as this kind of scales up and goes to different levels?"
They didn't worry about whether or not they captured
all the data without perturbing the system
they were monitoring, which was something
that we were particularly interested in doing,
and they were very successful doing that.
It was a challenging environment for us there for a while.
Another piece that's interesting in the same sort of space
is understanding who you're selling to
and who you're talking to
because they're not always the same people,
and with that same monitoring set,
we had users who were just adamantly
opposed to this product coming in.
Oftentimes it was, "We don't have problems,"
or, "We never see these issues,
and so we don't think we need it,"
and it took us a long time to recognize
that the real challenge a number of these users
were facing was they felt a little threatened
by a product coming in to kind of smooth this over
and do this faster than they could do it manually,
and the reality was,
and once we kind of understood the users we were talking to
and had the right level of conversation,
was, you know, many users got promoted
because of the platform they were using.
Because it had this extreme accuracy,
it meant that they had ease of debugging for their networks.
They could see things that they couldn't see before.
They oftentimes had much, much faster time to resolve
because they could see the right data quickly.
The system would help with that,
and ultimately, they had better data,
and in some cases,
real data where it used to be more suspect,
real data to actually take through
and do management reporting and explain
the nature of the business from their perspective
up into their management teams,
and this ended up being an enormous win
for a lot of the users, but until we had
the right verbal conversations to understand
who we were talking to and what it was
that they were trying to do day in and day out, it was...
Until we did that, we weren't able to make them successful.
And once we understood that, we were able
to take that step back
and really help them to be successful in their role,
so I think overall, the key is really working
with a group of people to solve the right overall problem.
Big chunks of that problem are going to be technical,
and big chunks of that problem
are going to be business-related or market-related,
and it actually takes all of that
to actually have a winning solution in almost every case,
and it's worth taking the time for yourself to reflect on it,
to think about it, to kind of not be defensive,
even if you get poked on things like schedules
and hurrying up because in the end,
you get a better solution, a better solution for yourself
and for your customers, which is what you want.