Hack It, Pack It, Stack It: How Not to Waste Money on Software You Don't Need
Make Sure You're Solving the Right Problem and A 2023 State of MarTech Appreciation Post
In the 1970s Kodak dominated photography. Like the Kleenex of its day, Kodak was nearly synonymous with photography.
Their foothold on the top of mount industry seemed unshakable. And for a competitor in film technology, it was.
They were the industry Goliath, but they made one fatal misstep.
Rather than embracing and investing in the emerging digital camera technology, Kodak focused on cutting costs and maintaining its traditional film-based business model.
The company spent years and millions developing systems that could produce film more cheaply.
And it worked: The company was successful in making film production more cost-effective.1
But it failed to recognize the shift toward digital photography.
Kodak's emphasis on cost-cutting, without a simultaneous commitment to innovation, proved to be a critical mistake.
Eventually, digital cameras became the norm, and Kodak's film-based business declined rapidly.
The company filed for bankruptcy in 2012.
Should we fault the engineers for failing to make cheap enough film?
No, they did their job. They designed a cheaper
Should we blame the marketers for failing to convince customers that tradition beats innovation?
No. And that's a tough message to sell to a nerdier customer segment anyway.
Should we blame the businessmen who bet the farm on film photography?
Yes. An important part of business is managing which problems get solved—not just if problems get solved.
The leadership at Kodak had bet on a film strategy without regularly checking in on their customers.
All those millions of dollars and hours could have been spent (at least partially) on digital technology. Kodak should still be a household name.
Before they went all-in on physical film technology, Kodak should have tried smaller initiatives of both cheaper film and better digital technology.
Kodak should have seen the sunk-cost fallacy in their approach.
Kodak should have made sure they solved the right problem.
How to Solve the Right Problem
Introducing the Hack It, Pack It, Stack It Framework
Scott Brinker (of Chief Martech) and Frans Reimersma (of Martech Tribe) just released a great MarTech report.
They pulled together useful materials such as industry expert opinion and stats on industry trends2.
But what was most interesting was a new framework. This framework makes sure you’re solving the right problem before you go too far down a path.
Of the 93 page report, this framework covered only half a page of text on page 9.
Good things come in small packages.
This framework lays out a neat, 3 step plan to figure out if a software is good for you. Instead of throwing money into a digital fire, try this out:
Hack a solution together manually. Find out if your company or department even like the end result before moving on
Pack it together. Remove unnecessary data and integrations, but keep a closer eye on this code for this.
Stack it up. Now that the solution has proven that it’s useful and people like it, you should build deployment-ready code. Then add it to your tech stack
With its catchy name, the Hack It, Pack It, Stack It framework was born.
When to Use the Framework
The Hack It, Pack It, Stack It framework is a great approach to determine if you’re not sure your solution solves a problem.
I know that sounds weird, but it is much more common than you’d expect.
The Bow-Tied Sales Guy has a great summary of what that might look like in the physical world.
Without a goal, a problem isn’t really a problem.
Let’s say your car died and now you can’t drive anywhere.
That’s a problem right?
Not so fast.
What if you’re working from home and everything you need is within walking distance of your apartment?
In that case, your car dying is not preventing you from accomplishing a goal, so you hold off on fixing it.
Actually, your car dying presents a new opportunity:
Save time & money on commuting and walk more.
But then all of a sudden your employers’ work from home policy changes and they demand everyone return to the office immediately.
What do you do then?
You get off your ass and fix your car because if you don’t you will get fired.
The car dying has now become a problem because it is preventing you from accomplishing a goal, which is to make money, so you decide to fix the car.
Use the framework anytime you need to validate if a solution solves a real problem.
How to Use the Framework
In the business world, there are software solutions for every business problem.
The question is no longer “Can we fix that?”.
The question is now “Should we fix that over something else?”
If your manager complains about how much time they spend scheduling meetings, you can find a software solution to that.
But this is where the Hack It, Pack It, Stack It framework shines!
Before signing on the dotted line before you know if something works, try something small to make sure you’re solving a real problem.
Step 1-Hack It: Try solving the problem with a hacked-together solution.
Goal: Determine if the solution matters for the business
Actions: Offload the work for someone to do manually for a few weeks or build a one-off API app on a free tier for a scheduling application
Result: Your manager saved 4 hours / week for the test period
Step 2-Pack It: Build a more reliable solution to continue validating
Goal: Determine if the solution scales well in a larger test population
Actions: Build a more robust application for scheduling or try a small tier for an existing tool. Gather data on a larger test population
Result: The average team member is able to save 2 hours / week with the solution
Step 3-Stack It: Integrate an enterprise-scale solution with your tech stack
Goal: Roll out a zero-maintenance-scale tool for everyone in the company
Actions: Build or buy a full-scale enterprise solution. Integrate it into the tech
Result: All team members can use this tool ad-infinitum
When Not to Use the Framework
This framework does a great job for teams that are agile, but doesn’t necessarily work in all cases.
Don’t use the Hack It, Pack It, Stack It framework in a few cases:
If your industry is highly regulated
Hacked solutions are not appropriate if there are potentials for regulatory fines
If your company is entirely waterfall
If approving a hacked solution takes the same effort as a full enterprise solution, don’t start with the hacked solution
If your team is already at 100% utilization
If a new initiative would immediately get dropped or not properly maintained, don’t start something new that’s highly manual
Use your judgement to tell if the framework is right for your conditions.
Conclusion
Validating that the problem you’re trying to solve is worthwhile is an important first step in any business.
The framework laid out in the State of MarTech 2023 report introduces a great 3-part framework for doing this.
Hack It—Try it with an ugly solution
Pack It—Make it repeatable
Stack It—Fully integrate something
If you’re not sure if something solves a real need, try this framework before jumping in the deep end.
Good luck hacking your next solution!
The investment would have paid off if the market for film had grown at the same CAGR as it had in the 1960s and 1970s
I have no idea how they keep track of the # of MarTech tools in the space. It seems like a Sisyphean task, and I’m grateful I’m not in charge of the effort.