Product Hacking: What is it, why you should have and how to start

Leia em Português

Have you watched Cake Boss? Cake Boss is a TV show that shows Buddy Valastro and his family baking monumental thematic cakes.

Yes. This is a cake.

If I needed to build this kind of cake, I would certainly like to have a specialist team: On toppings, fillings, chocolates, dyes, top notch suppliers and mostly, a leader that could put all together perfectly. And this is only the cake, imagine the whole party.

Drawing a parallel, I would like to approach this for another angle. This is my grandma Maria, cutting her last birthday cake. She planned the party, bought all items and baked the cake. It was absolutely delicious. Totally surpassed my expectations.

No doubt there is reason for both types of cake, but if we think on demand, which one has more? Wouldn’t the Cake boss team be too much for the biggest portion of world cakes? and the cost of keeping this team? and the effort to manage, communicate and align? What if we build this team and for some reason the cake goes wrong? Would be a huge failure.

I believe that same is happening on companies. Many of them are trying to build more specialist teams with less scope — Maybe an attempt to reply reference companies models in different contexts — A lot of complexity, few problems effectively solved.

Having this in mind, we suggest an alternative, or better, a complement to companies specialist teams…

What is Product Hacking?

Product Hacking is an hybrid team with business, project and technology know-how. We like to say that our people is like “one-person army”. Each person is allocated in one company branch/area, where they will learn about main goals and challenges of it. Then, they can raise improvement opportunities, evaluate impact, design a solution and implement the solution. Some projects examples are code integrations between platforms, enable a new third party software, structure a new process or really… anything. We don’t have many boundaries. Our hypothesis is since one person owns the problem and the solution, the final product end up consistent, fast and useful.

The team arised at Creditas in 2016 with a generalist who liked to exam processes and solve bottlenecks with automation. With time, Product hacking delivered more and more solutions and value to the company.

However, some issues started to emerge on Hackers solutions:

1. They weren’t designed to be scalable and could fail with operations and company growth at any time.
2. Many supported critical operations, which resulted in chaos if something goes wrong.
3. Not always best practices in technology and infosec were applied, difficulting maintenance and exposing company to risks.
4. They could be concurring or opposing to Product Technology main solutions, leading to bad synergy.

For those reasons, Product Hacking figures inside Product Technology team as a complement. Coding and architectures best practices are used and solutions synergy are frequent.

In fact, Product hacking proven valuable solutions are absorbed by Product Technology team to be evolved. So, we have the best scenario: A agile team build the initial version and evaluating business hypothesis and a specialist team, to build really decisive sturdy products when they are needed (remember the cake example).There are also Product Hacking solutions that fail, like any project team. The point here is that out projects are individual and fast, so the cost is way lower.

For this features, we are specialist good in two situations: MVP building for hypothesis validation and crisis resolution, since the delivery time is usually the most important factor.

Why you should have

1) ROI

As I stated before, all projects are submitted to impact versus effort analysis. In last two quarters with 15 people, we delivery BRL 7.5MM estimated impact on EBITDA with our solutions by increasing revenue or reducing costs. More, our projects bring another unmeasurable benefits, such as faster business maturity (through hypothesis validation), user experience and risk avoidance.

2) People development

We are based on the premise that people can deal with more than a small part of job to be done inside a company. Maybe opposing what happened on industrial revolution.

Therefore, since we dont hyper-divide the job, one person can think with several heads (technology, operation, sales, etc) approaching the issue by all points of view. Additionally, as all solutions are different, our employees are always out of comfort zone, learning at a higher pace. In general our people receive wonderful feedback from stakeholders, being recognized as great problem solvers and impact generators.

3) Communication and alignment

For being a team with many knowledge and interfaces with stakeholders, we end-up playing a role of grouping efforts and engaging several areas into complementary actions. Despite of that not be a formal assignment, our people are in great top view position to contribute on process and product structuring.

How to start

Of course this model has challenges. Today Product Hacking faces a strong workload to keep up with company news and quick react to business updates. On the other hand, this effort pays off because enable us to take shortcuts and be much more assertive on solution propositions. Also, it’s not easy to find the right people, hire and develop then. However, the feedback received and impact generated shows that worth it.

Work Model

Our structure holds one manager, two Team Leaders and twelve analysts. Leaders are responsible for managing activities, roadmap/backlog and deliver quality assurance. Sometimes we also take part on problem discover and solution conception due to higher exposition to company context.

Analyst are responsible for projects. Typically each analyst have one or two projects running at the same time. Some analyst are seniors and also hold the responsibility to mentor less savvy people and helping on projects.

The project steps are:

1. Find the real issue/oportunity interviewing keys stakeholders.
2. Evaluate the value of deliver a product on this issue versus elsewhere.
3. Design an solution
4. Implement a solution — This can be a coded product calling micro-services/APIs, a third-party platform, process structuring or anything actually. We don’t really have boundaries here.

Our project developing cycle is typically 1–4 weeks, depending on complexity.

Environment

During our journey, we’ve learned some things that work, and other that don’t. I want to highlight:

• Support and alignment with technology team — We work together with technology, usually building initial versions. Is too expensive mobilize a full technology team to build a feature to check an hypothesis.
• Creativity — Be creative for what is problem solving. Sometimes it’s possible to solve by talking. Coding should be your last resource.
• Versatility — To allow that people can flow to most critical areas and work on relevant matters.
• Scientific Method — Define scope, hypothesis of impact and measure results.
• Knowledge sharing — Develop a strong information exchange and team work environment.
• Documentation — ALWAYS keep good documentation. Very important to reuse solutions and handover to technology.

People

It is not easy to find the right people and develop then in so many skills. frequently someone who has more tech skills, lack on business/product skills and vice versa. So, our hiring is totally based on this profile: Logical and data-driven thinking, willing to learn, versatility, critical thinking and wide sight.

For people development, is necessary a safety environment to enable errors. Also, is necessary to include most diverse backgrounds on the team. After that, we need to expose people to level increasing challenges all times, in the right dosage. Besides, we have mentor program (seniors develop juniors) and we hold a bi-weekly training about several matters (usually tools and skills).

Hybrid professionals are incredibly valuable and end up being very effective on problem solving and delivering impact, frequently surpassing expectations, just like my grandma. I believe we need to revisit how companies faces challenges and how we hyper-divide and lag new initiatives.

After all… Who doesn’t love grandma cakes?