New products need hacks to succeed
If you’re genuinely doing something new and, dare I say it, innovative in a large company then you’re going to need to hack some of your organisation’s existing systems for technical or political reasons (or both). It’s one of the dirty little secrets that no one talks about as an essential ingredient for successful innovation. I’m not kidding, I see the need for this every week.
Usually everything starts off on the right foot. The product or business team follows some “innovation process” like Design Thinking, Double Diamonds and A Hypothesis-Driven Approach. They then generate some ideas based on their work. The ideas begin to take shape and are shown to “the IT department” (it’s always called that in this situation, so I’ll roll with it).
This is where the innovation fairy tale falls apart. IT tells you it can’t be done in a million years, “not technically possible”. Or, IT takes it on and gets the easy part done but avoids that core use case that makes it new and exciting.
That core use case usually needs some creativity and technical ingenuity to, quite plainly, hack something together. For example, we recently had to reverse engineer a multi-billion dollar software package to get data on the status of every employee’s schedule (their schedules definitely weren’t in Google calendar, this was more archaic).
This post is about how to turn the obstacle of the need to hack into the creative feat of technical and social engineering that allows you exciting new product, initiative or venture to come to life. It will cover:
- Why hacks are needed in the first place to bring new products or initiatives to life
- How to overcome the politics and negativity surrounding hacking something
- What types of hacks you can use
- Who you need on your team to succeed (hint: they were usually rebellious kids)
Why are hacks needed?
Hacks are needed because most new tech products are trying to leverage a company’s existing offerings, assets or data. This means interacting with existing systems.
Interacting with existing systems is often such a complex exercise that an entire industry with global corporate behemoths like Accenture exist solely to integrate different systems. With your new product development many integration points will be straight forward – standard integration development. But, almost every time there will be one or more interactions that require a hack.
The hack(s) are required because you’re usually trying to do something the existing system wasn’t designed to do.
It gets better though:
- If the system was bought or licensed, the vendor has no intention of supporting your use case. Sometimes they will actively work to fight it.
- If the system was built or is ‘owned’ by another part of your organisation they may have no intention of supporting your use case. Sometimes, just like the external supplier, they will actively work to fight it.
The actively fighting part happens regularly. No judgements placed here, there people actively fighting the use case you need often have good reasons. But don’t let that stop you, any good innovator needs to overcome these challenges. Even if just for the sheer thrill.
How to play the politics of hacking your own company
Before you get onto the technical fun of hacking something you do need to lay some political ground work. Hacking systems owned by other parts of the company can start some internal fights and hacking systems from third-parties can lead to rooms full of lawyers.
Here are a few tactics that have worked in the past in no particular order:
- Get the right executive sponsor and champion onboard. This might be the CEO, it might be the owner of the system. Failing that, get some executive aircover.
- Workout whether you want/need to let anyone know about the hack. You might decide to delay until it is actually working, sometimes a demonstration with a completed hack is a 1,000x better sales tool. Then share and onboard people (or switch it off)
- Make sure people understand the compelling need for the hack. Restate the opportunity.
- Highlight that the hack might be temporary if it helps the new product succeed (if this is true of course).
- Assess the legal consequences of anything you do.
- Make sure people know this is actually business as usual for doing something new. Often people get so riled up about “scalability”, “quality” and “we can’t hack” that they lose sight of the opportunity and getting an outcome. Telling them it is normal might help.
What types of hacks are there?
You may already have an idea of what your hack will be. But if not, here are some ideas to help get the brain moving:
- Dumping data from the “enterprise database” or databases into your own database.
- Monitoring network traffic to find out the data protocol (some say API) being used to communicate between an app, servers and the systems you need to work with. Often the mobile app is clearly fetching the data you want but the vendor or owner tells you they won’t give you the API definition.
- Reverse engineering software. Be careful with this one, it isn’t always legal.
- Accessing a system another department has told you not to. Yes, technically it is easy but it often takes someone with courage to proceed. More of an emotional hack I suppose.
- Scraping public data sets.
- Scraping or manually exporting/formatting company data sets to get the data you need in the timeframe you need rather than waiting for official channels.
- Mocking the existing system with close to real data (so close no one notices for a while).
- Injecting code into the web browser. They may not have an API but Chrome and Firefox let you write scripts that can manipulate what a user sees.
- Mechanical Turking it – using a human in the loop to make it look like there is a smart algorithm or integration in place. In reality, someone is pressing some buttons in the background.
Who you need on your team to hack
Cross-functional teams are an excellent starting point. The earlier the right type of engineer or data scientist is involved, the earlier you can shape the product inline with what is technically possible. Unfortunately, the reality that usually plays out is that organisations don’t see the benefit of this so business/product people operate in isolation then a redesign is required. Push for an engineer involved early but if you can’t get the budget then snoop around for something with the right fit.
The engineer with the right fit for the type of hack required would probably do it just for fun. So worst case you might be able to get it done “outside the budget”. The right person for this type of work probably had trouble following instructions in class and probably has a background with a few crazy adventures.
Good luck. You’ll need it, but it’s worth it.
Finally, to be clear, nothing here is promoting unethical or criminal activities. Instead, it is giving you a framework to progress new products through corporate reality.