Stretch Your Thinking and Focus Your Action
a.k.a how we innovate without shooting ourselves in the foot
The benefits of focused action are generally well understood, as evident by the widespread use of minimum viable products and agile software practices. Focus is also at the heart of good strategy and personal effectiveness.
By limiting scope and focusing effort on a few priorities, we test assumptions quickly, get early customer input, iterate more often, deliver real value, and reduce risk. Plus, our stakeholders appreciate the visible progress over time.
But while focused action is very important for success, it’s not sufficient by itself. For truly transformational tech products, I believe you need to cultivate a counterbalance to focus — i.e. to deliberately stretch your thinking.
So today I’d like share a few tips from our experience using the “stretch your thinking, focus your action” mantra at Certsy, an in-house startup at SEEK.
Cultivate a mindset of playing, not planning
When we say “let’s stretch our thinking on this”, we mean it to be a creative exercise rather than a purely logical one. Think of it as a chance to play with possibilities, and imagine the implications if various futures happen to unfold.
This is not about trying to plan for all scenarios. It’s just about stretching our core concepts and ideas to see if they can plausibly cope with possible futures, or if we need to re-think them.
The beauty of this approach is that you don’t need a definite roadmap or plan, nor a comprehensive set of predicted scenarios. You also don’t need to know exactly how you will solve everything in all scenarios. It’s just about getting a sense of comfort that, whatever the future holds, you’ll be able to manage.
For example, in the early days of Certsy, we had to model core concepts about people, documents, credentials, and how they relate to each other. Our only concrete example was our very first credential (i.e. ‘right to work’) but we often tried stretching these concepts to see how we might verify a host of other claims on a person’s CV — e.g. university degrees, licences, registrations, work history, etc. This was very helpful despite lacking in-depth knowledge of each credential, since we still captured the essence of what was different and what was similar.
Assumptions grow up to become constraints
Years ago in engineering design lectures, I was taught that it’s much easier to rub mistakes out on paper than in concrete or steel. It turns out that this basic principle applies equally well to production-scale software (even with agile).
Early product and engineering decisions are critical. Your many assumptions – large or small, implicit or explicit – get deeply baked into the architecture of your system. The more fundamental it is, the more difficult and costly it will be to change.
There’s no escaping the need for assumptions. But what you can do is make the critical assumptions clear and visible for the team to debate and align on. And using the techniques below, you can pressure-test your thinking and make sure that (most of) your future changes are ones you half-anticipated.
For example, employers on SEEK can add screening questions to their job ad for candidates to answer when applying (and optionally verify through Certsy). One critical assumption we made early on was that the structured library of questions and answers would be dynamic — so we built our systems accordingly. We still get some issues when questions or answers change, but nothing major.
Try to spot the likely vectors of change
Our engineering lead often talks about ‘vectors of change’, by which he means “how do we expect our system requirements will evolve?”
Knowing the likely vectors of change means you can architect your system with relevant concepts that can flex and extend in those directions at relatively low cost.
You don’t need to know exactly what will change, or how, or by how much — all you are saying is some sort of change in this broad direction is expected. If change happens along the vectors you expect, then the engineering work is often fairly minor. But when an unexpected change vector emerges, this can fundamentally break your assumptions and cause major delays or refactoring.
For example, with Certsy we figured that success would mean we’d probably have to handle (i) more users (ii) more credentials (iii) more authorized partners, and (iv) different verification mechanisms. However, we chose not to handle the change vector of “more countries” upfront, given we already had plenty on our plate and we lacked sufficient domain knowledge at the time to prepare for it.
Feel the pain before solving it at scale
As you stretch your thinking, you’ll probably identify a host of problems that could unfold over time. It’s often tempting to be clever and try to solve these issues early in a scalable, automated way. Resist this urge and stay focused!
Stretching your thinking is not about solving all the problems in advance — it’s just about identifying vectors of change, playing with key concepts, and getting confident that if and when stuff happens that you’ll be able to cope.
One simple but effective practice is to commit to feeling the pain before you solve it. This means you avoid the wasted effort of solving potential issues that never materialize. It also provides valuable learning as you gather data and insights, and cobble together an initial manual solution. Hence, when you eventually commit developer time to solve it properly, you know the problem is real and that your solution works.
For example, when Certsy starts verifying a new credential, our operations team relies a lot on manual processes within a very basic admin portal workflow. This is because the really useful insights and workflow improvement ideas come from hard-won experience in actually doing the work. Only once we have an efficient manual approach with well-understood edge cases do we actually build out more automation and tooling. (And the few occasions where we tried to be too clever in anticipating what the workflow should be, we’ve ended up regretting it!)
Make the future look tangible
Another useful technique is to create mock-ups of the long term product vision. We try to imagine what the product looks like in a few years when it is super successful, with millions of users and a mature value proposition.
Even a basic wireframe is good, but a credible high-fidelity mock-up is better. Relax, you’re not promising to build it as shown, nor are you claiming that it’s optimal or well-tested. You’re simply playing with ideas and sharing them.
One benefit is that this design process forces you to think in a disciplined way. You can’t just wave your hands and say it’s going to do all these wonderful things — you have to actually lay out an information architecture, populate it with examples, visualize how users would undertake certain tasks, etc. This thought process helps to refine your product strategy and proposition, and also further pressure-tests whether your underlying concepts can stretch.
The other big advantage of visualizing your product end-state is communication — there’s nothing as powerful as a well-thought out visual artifact to quickly bring people up to speed and excite them about the future. And even if they dislike it, that’s fine too —it has provoked a specific response and given you an opportunity to be curious and tease out their perspective.
Chances are good that at least some elements of your product vision will resonate with others, and with further input and reflection you can evolve it into a compelling pitch. Who knows, maybe a senior executive will end up saying: “I like it. When can I have it?”*
For example, before Certsy even had a team we mocked up a basic wireframe in Balsamiq to show what a mature product could be —which helped convince a senior executive* to support our business case for initial resourcing. More recently, we created a Product Vision pack with an ambitious, high-fidelity picture of Certsy in a few years. So far this is having a great impact with senior leaders, provoking useful debates about our strategy and opportunities. And within Certsy it’s helped refine our thinking and really energized the team.
Conclusion
For us, ‘stretching our thinking’ is one way that we try to align to and bring to life SEEK’s cultural belief about doing the right amount of upfront thinking. Of course, there are plenty of other aspects of good upfront thinking not covered here, but perhaps we can explore those further in a future article…
In the meantime, I hope you’ve found these tips and Certsy examples useful. Please feel free to share in the comments your own perspectives, insights and lessons. How have you focused your action while stretching your thinking?
If you found this article helpful, please applaud, share, and/or follow.
