Report: “Product”

2018 March

You can read the Product report from Gunar here and from Robbie here.

Summary

As I onboarded this month, I focused on gaining a high-level understanding of Invisible, identifying some of the most important and pressing issues, and proposing solutions to them. These are what I will cover in this report.

As a Product team, we focused on building the most important systems first. These included work on:

• Automated Dashboards
• Improved Routing
• Texting, Calling, and Slacking your assistant
• Centralization of information within Invisible
• Automated tracking of Processes, Instances, and Spending
• New CRM setup using Hubspot
• Identifying important Metrics and their dependencies
• Designing an evolved Digital Assembly Line (DAL) to become more efficient, scalable, and robust

I worked on the above bolded points and will delve into those. Check out the other reports for details on the rest.

My Onboarding

When you join most companies, they tell you that the beginning will be like drinking from a firehose. All my previous companies told me that. Invisible is the first company to deliver on that promise.

Invisible has systems for everything. Systems for their systems. And because it’s completely open, all the company information is there to learn. It’s a lot.

Invisible is honest. They tell you why you shouldn’t work here up front. If that doesn’t deter you, and you’re in it for the challenge, then it’s likely a great fit. For me, I resonate most with #4 on the list of what I will do for Invisible:

Do it because you want to do something on the edge of hard and impossible. Do it if you are the unstoppable force seeking an immoveable object. You want to see what you’re made of. Do it if you want to test your limits: your ability to create order in chaos, to operate under extreme stress, to achieve impossible goals.

Invisible is delivering. The expanse of challenges are immense, but so is the responsibility. On top of that, the culture of direct feedback means I’m getting strong intellectual pushback, receiving positive feedback, and having areas for growth pointed out every day. I love that.

This is all to say: My onboarding wasn’t easy. But no surprises there.

Problems and Solutions

1. What is most important to Invisible? → Metric Dependency Tree

The first question I asked Francis when interviewing for Invisible was, “What is your single point of optimization?” That is, what is the ultimate metric that we strive for, that everything we do boils down to. Long term valuation was his answer.

I believe that a strong company should be aligned, focused, and efficient. For that reason, I started my understanding of Invisible by mapping out what matters to the company. While our reason for creating Invisible might be because of our mission, the direction we grow will be based on our metrics. So I quickly mapped out our top-level metrics in a way that follows logical entailment; improvement of child nodes on the tree necessitate improvement of the parent node.

Our top-level metrics. Current iteration.

Then to maximize team focus, I mapped our org chart to our target metrics.

Team Structure. Current iteration.

This accomplishes a few things:

• Creates complete company alignment on what is important
• Lays the groundwork for a decision making framework regarding task selection and resource allocation
• Focuses responsibilities for each team and individual to a single metric (useful for forecasting later)
• Increases velocity by minimizing stakeholders for each project or decision

Of course, this is just the current iteration. There is always room for improvement.

Currently, I am compiling metrics and categorizing them into the following:

• Target Metrics — The only metrics we care about as a company. Focus on these metrics above all else. These lead to success.
• Hypothesis Metrics — These are NOT valid as indicators of success unless the change was predicted and confirmed by an A/B test. This is because it subjects us to inadvertent data dredging and p-hacking and natural variance. To use these correctly, construct an A/B split test following the scientific method.
• Vanity (Informational) Metrics — These metrics are too far removed from the Target metrics to be reliable. These should never be used as metrics for success because they do not necessarily correlate with an increase in valuation (our single point of optimization). Using these will only give us a false sense of security. Caveat: they are useful for identifying places to dig deeper and create hypotheses.

2. What is Product anyway? → Organized Product Team

March saw the formal creation of the Product Team. Great. But what is product anyway? Product is a nebulous term thrown around, but to understand how to focus our team, we needed to focus in the right direction.

After creating the above team structure, we see the duties of the overall Product team encapsulating three (later) separate teams:

• Product — In charge of optimizing Customer Lifetime Value
• Project — In charge of project selection, management, and resource allocation (Engineering and Design)
• Strategy — In charge of finding inter-team problems and solutions

For now, our team balances all three of those responsibilities.

3. No CRM or easy way to track client data → Hubspot

When I joined, all of our client data was spread across multiple files and emails. When the client is your number one concern, you need a system. As a longtime user and advocate for Hubspot, I pitched this, we discussed, and it got implemented.

Now all client information, emails, and requests are automatically tracked and accessible in one place.

Benefits of having a single source of truth for all client info:

• No information is lost
• Lays the groundwork for future automations, both on the marketing and product side
• Begins collecting data needed for all client metrics (e.g. response time, requests per day, etc.)

4. Digital Assembly Line inefficiencies → DAL Evolution proposal

Skyler has also created a One Bucket proposal that is the next iterative step. This covers my DAL Evolution proposal, which is a description of the ideal DAL. The DAL 2.0 mentioned in Gunar’s report includes both of these proposals.

Issues with our current DAL

• No single person is responsible for any task
• Any throughput blockers slow down the entire assembly line (failing SLA)
• Scaling is linear

After lots and lots of iterations and implementations of models from computer science, evolution, and economics (which I will omit for the sake of brevity), I came to a solution (the DAL Evolution) that can most simply be described as “recursive outsourcing”.

The DAL Evolution’s user experience functions much like Uber — tasks (rides) on demand, fulfilled by agents in an elastic supply-demand setup. The benefits of moving towards a system like this is that:

• One bot that can actually do everything
• No client request will ever be dropped, late, or completed incorrectly
• Optimal dynamic pricing — guarantees lowest possible pricing automatically
• Auto load balancing — We can assist any client since it scales horizontally/vertically as needed
• Exponential scaling
• Possibly automated agent training

Theoretically, this is the way to go. It’s the implementation details, specifically a transition plan, that make this tricky. Logistically, less recursion is both easier and more likely, and my model could’ve incorporated self-automation as well from Builders (two of the points that came up in my conversation with Francis), so I am now on a quest to improve the DAL Evolution and design the simplest transition plan in conjunction with the Product team’s DAL 2.0 work. The work under the DAL 2.0 umbrella is lofty, but the gains are immense. Consequently, this will be one of the highest priorities for the Product team going forward, and we’re already syncing with the Operations team to make this happen. The key to success will be to implement the smallest changes that will have the greatest impact.

Reflection

Onboarding is a long road, but I’ve learned a lot, and we’re moving in the right direction as a team. Many of the pressing issues are being addressed, and we’re getting more aligned each day.

All that being said, the Product team can definitely move faster (and we will). We need to find the best solutions that are quick to implement. We need to work more closely with Operations and Support to understand where they are at a deep level. We need to comb over the experience of our customers and solve their issues.

Our initial product systems are in place. Now it’s time to accelerate.