Sparking Intrapreneurship: Finding High-Impact Project Ideas
Hello folks!
If you follow me on LinkedIn or have taken my course or coaching, you’d have heard me talk about Intrapreneurship - a style of leadership that I encourage big/mid-tech ICs to embrace. Today I’m kicking off a series where ChaiTime will periodically host Intrapreneurs to talk about various aspects of their journey.
My first guest is
, a staff engineer at Stripe and a fellow Substacker! Sidney will be talking today about where and how he finds high-impact project ideas.Over to Sidney!
You've probably seen teams delivering 'cool' projects that bring significant value to the organisation, such as new products, cross-product features or dev velocity accelerators. Sometimes, you'll notice the same people involved in these high-impact projects. You may have thought, 'Where do they get these great project ideas?'. At Atlassian and Stripe, I've been lucky enough to work with people like this, and I have had a few high-impact projects and ideas of my own.
Successful high-impact projects start from the seed of a good idea.
A good idea for a project is a matched combination between a valuable problem to solve and a solution that fits within business constraints.
As technologists, it's very easy to latch onto a cool new technology and then try to find use cases for it, often coming up with many use cases where the tech could be helpful. Unfortunately, this is a 'hammer in search of a nail' (or Shiny Object Syndrome). Projects starting from this rarely see sustainable success as the value prop is not present; your tech could be the answer, but there are likely many answers, some of which may already exist or are faster to achieve.
At the other extreme, some project ideas come from a great sales pitch with no technical backing: We will solve problem X, which has a massive "Total Addressable Market"; it just needs a 'small matter of programming'. These projects get funded and announced at major company events, only to fizzle away as progress is hindered by technical challenges and simply how much work it actually is.
So, where do good high-impact ideas come from?
While it is probably true that 'ideas can come from anywhere', I've found the following areas to be good sources:
Repeated problems that are considered 'too hard' by others
When you hear phrases like 'Oh, we tried that before' or 'Lots of users have asked for that, but we can't or haven't because...', it's a sign of an area ripe for high-impact ideas. Solving these problems was probably hard in the past, but constraints may have changed in the meantime that have reduced or eliminated past challenges. More users might be facing this problem now, making it worthwhile to solve. Or there might be new knowledge or technologies available, perhaps cross-pollinated from another domain, that can make a solution far more feasible.
One example from my time at Atlassian: integrating newly acquired products with an existing platform is always challenging, and past experiences with Bitbucket and HipChat left scars. However, as Atlassian proceeded with more acquisitions and the Atlassian Cloud platform matured, there was an opportunity to rethink and focus on solving this 'too hard' problem - i.e. the business value increased and more viable solutions existed. We built smaller 'platform bundles' for infrastructure, user management and authorisation, and shared editing experiences that streamlined work for Trello, OpsGenie and a revised Bitbucket integration.
Another example at Stripe: While we have always sought to better integrate our products (e.g. Stripe Issuing with Treasury, Capital and Payouts), 'legacy' has always made this quite challenging and difficult to justify extensive work. However, technological advances such as the recently announced multi-currency financial accounts have changed this equation significantly, allowing us to build more cohesive products for our users.
Lots of product and user discussions
Great engineers I've worked with have an ability to identify patterns and abstractions that can solve many problems at once, including those we don't know yet. We need to seed this abstraction engine with as much context as possible, and the most pertinent context comes from our users (external for products, internal for platforms). Learn as much about your users as possible, including their business models and problems they are trying to solve. Watch as many user interviews (live or recorded) as possible. Interact with those who directly work with users - product managers, solution architects, etc. Depending on the organisation, engineers may be shielded away from users, so this might require overcoming inertia, e.g. working with product managers and sales to set up 'sales call rosters' that engineers sign up for.
Role-playing as different stakeholders to find gaps in your systems
Users can usually tell us about their current problems, but cannot always tell us about the issues they might face in 12+ months. Also, those you typically consider users are not the only source of requirements for your system; there are likely other (internal) stakeholders like security or legal teams who may not even be aware your systems could help them solve their problems!
You can role-play (especially with product managers) or collaborate with stakeholders to "think ahead" and find high-impact project ideas that are not immediately obvious to others. At Atlassian, while I was a 'product platform' architect, I had a very productive relationship with security (in a different org) that resulted in initiating and delivering cross-product/service security policy enforcement projects and corresponding user-facing features. These ideas would not surface through typical user interviews or be discovered too late for us to build extensible and scalable solutions.
Researching problems solved by others
While every organisation has unique value propositions, most of what we build is similar to at least some other companies; colleagues have noted that I've said, "We're not that special" many times! Instead of seeking to reinvent the wheel, I've found seeing what problems others have solved to be a great inspiration. There are always other companies that are more advanced in certain areas than yours, so why not take what they have learned? The key is understanding why they did what they did; your situation may differ, so your solution may need to be tweaked.
At Atlassian, we wanted to provide a unified view of data in our products. For example, "issues" existed across Jira, Trello, and Bitbucket, so why have multiple APIs and representations? I started an initiative to develop a framework and tooling to produce and manage a canonical cross-Atlassian data model. My starting point was investigating what other companies had done, e.g. Microsoft Graph, Facebook Tao, LinkedIn, Stripe. The result was a unique solution due to Atlassian-specific constraints, but was heavily influenced by learning from others.
Preparing yourself to find those high-impact ideas
Great project ideas don't arrive on a schedule or when you want them. However, with the right mindset, they become easier to find.
Be curious
Engineering is a lot about instinct. As we gain experience, we create mental models that enable us to detect if something feels wrong or that seemingly difficult problem feels possible to solve. We need to get into the habit of being curious and doing something about that feeling, spending time to better understand the problem, researching possible solutions, prototyping, etc. This curiosity allows you to find and thoroughly test your project ideas. For example, hearing those repeated problems considered 'too hard' by others should trigger an investigative response.
Finding the time is challenging with our regular day jobs, and also if you have a busy personal life. It is crucial, especially for senior engineers, to negotiate "quiet time for investigative activities". I've found it easier to schedule mini-investigation 'projects' where I or a small team can sprint on a topic; at Stripe, I (and other similar engineers) have used this approach to prototype new cross-product integrations to garner support for full projects.
In addition, leverage hackathon-style activities where possible. Hackathons are not simply the 24 or 48 intense hours on a project; they are a framework where you can do preparatory research, test project ideas, and pitch to a relatively captive audience to get traction for future work. Several of my successful project ideas at Atlassian, including how to integrate user authentication for acquisitions like Trello, were researched and tested during hackathons.
Find your people
Getting high-impact projects off the ground is rarely a solo effort. Many startups have co-founders. You need others to compensate for your weaknesses and to be strong sounding boards to pressure test ideas.
Networking out in the wild can be hard, especially for introverts like me. Luckily, networking at work is much easier. During our regular jobs, we're forced to interact with others in various roles on projects and other cross-org interactions. Take the opportunity to learn about other people's strengths, who share your curiosity trait and whom you feel you could work closely with. When the seed of high-impact project ideas comes, you know who you can contact.
Building your network, especially cross-org and cross-functionally, also makes it easy for others to contact you when they have a spark of an idea that you can collaborate on.
Accept your ideas may not work...yet!
As mentioned above, good ideas are matches between valuable problems and solutions that fit business constraints. As you dig into a problem space, you may find the problem has less potential than you initially thought or that the solution is more costly or complicated than expected.
Don't be disheartened, and don't throw away your work. Save it for later. You may be able to repackage some parts for future projects. Or perhaps constraints change, such as a new regulatory requirement or the presence of a new system, affecting the feasibility of your project idea. It is extremely satisfying to pull out an old sketch of an idea and say, "Here's something I prepared earlier"!
Don’t chase glamour
One anti-pattern I've seen is engineers striving for moonshots and ignoring smaller, less glamorous ideas. However, small improvement ideas, especially in 'platform' systems, can have an outsized impact and snowball when many smaller, successfully implemented project ideas are composed. For example, at Atlassian, a 'small' idea for service-to-service auth (ASAP) enabled a system to easily and securely distribute user identities across all products, unlocking cross-product enterprise security features.
The lesson is to keep an open mind and not always seek the obvious glory.
Takeaways
My ultimate goal for this post was to highlight that coming up with high-impact project ideas is a skill we can all learn. It comes down to realising:
Finding good high-impact project ideas that match valuable problems with solutions that fit within business constraints.
There are specific places where we can source ideas, including:
Repeated problems that others have said are 'too hard' to solve
Product and user discussions
Role-playing as different stakeholders to find gaps in your systems
Researching problems solved by others.
We need to be open to finding good ideas by:
Being curious and digging into problems and solutions
Finding others you can work with
Accepting ideas may not be viable...yet!
Valuing 'high-impact' over glamorous ideas.
Sidney - thanks for sharing your thoughts on how to find high-impact good ideas!
Readers - if you enjoyed this article, check out Sidney’s other writings at
and be sure to subscribe! A couple of my favorite pieces are Planning for Your Replacement and How to Learn a New Domain Quickly.Sidney and I would both like to know what is your next high-impact idea and where is it coming from. Drop us a comment here!
 | A guest post by
|
Great article.
Waiting for the next.....☺️