The day after my first startup called it a day, I took a giant step back and looked at what had gone wrong.
Like any good tester, I set off exploring, discovering and learning.
Following ten weeks of customer development, I’d learnt a lot about an industry I knew little about. I’d gotten out of the building and grown in confidence meeting with industry experts for the first time. Fresh eyes on an archaic industry received both positivity and scepticism.
Yet the business idea, full of dependencies, was complex. This made it difficult to see if we were solving a genuine problem.
By week ten I’d lost the passion and knew it was over.
“I have not failed. I’ve just found 10,000 ways that won’t work.”
Determined not to give up, I kicked off another startup experiment. But before jumping in, I collected my learnings and created four takeaways.
Takeaway 1: Build within a familiar domain
After weeks in unknown territory, I wanted to feel more sure of myself. There’s enough uncertainty, not knowing what you’re doing in a startup, without also learning another industry.
Doing something in a familiar domain felt like the safer choice. I convinced myself I had to build a product related to my work-life problems. Sounds obvious right?
Cognitive empathy has got me through huge challenges in testing, placing me in the shoes of an end user. If I’m to build something based on my work-life, I’ll be an end user myself.
Takeaway 2: Solve a real problem
“The way to get startup ideas is not to try to think of startup ideas. It’s to look for problems, preferably problems you have yourself.” — Paul Graham
Successful businesses solve real problems. It seems so obvious. Hire a product or service to do a specific job to relieve pain and create gains.
I decided to focus on my industry, use my experience and solve my problems. I’m good at what I do, others will share those problems.
One of my jobs as a tester is to design and track tests. I’ve spent my career going back and forth between test management tools and spreadsheets, yet I’ve struggled to feel comfortable using either.
This is a problem.
I’ve experienced plenty of issues in QA: that last bug blocking a release; pressure to sign off a release though my gut knows it’s not right, or my personal favourite; discovering a change has been committed, it’s going live and everyone knew.
Why is there an obsession with automating every test scenario? What happened to good old exploratory testing which is the only way to really learn about a system under test? Automated tests should simplify checking, not replace testing. I’ve seen many a team get lost chasing the 100% test automation dream.
These are real problems.
Takeaway 3: Find your passion
“If you talk about what you believe, you will attract those who believe what you believe.” — Simon Sinek
After setting off alone for a few days, I got into conversation with an ex-colleague keen to know what I was working on next.
He’s a software architect, and we reflected on shared experiences of developing and testing.
I talked about a product concept and mocked up a simple sketch. Convinced there’s a more collaborative way to create and track tests, I started getting very passionate.
It was a joy to find out that my future Co-founder believed what I believed.
During our work-life we’ve endeavoured to improve how development teams run. Three approaches stand out:
- The retrospective. A team can lift itself from difficulty by a frank conversation in a safe environment
- The GROW model of coaching. Establish some goals, check reality, explore opportunities and agree on a way forward. It’s satisfying helping people answer their own questions
- Nemawashi. The art of individual chats to solicit feedback on a proposed change that affects many
We had been taking these for granted.
So we thought,
“Why don’t we build something that does what we’ve always tried to do at work!?”
Takeaway 4: Less. But better
The conversation continued. We saw an opportunity to build something simpler than any of the existing testing tools on the market.
We found in each other a belief in minimalism, simplicity and above all, quality. Doing less leaves space to do things as well as we’d always dreamed.
Products like Slack, Trello, Medium, OS X and Google Drive inspire us with their beautiful design.
These products aren’t solving new problems, they solve them more elegantly, simply and single-mindedly. Simplicity is about subtracting the obvious and adding the meaningful. This is our mantra.
“A Minimum Viable Product is not an excuse to throw our beliefs about quality out the window.” — Eric Ries
Building an early stage tech startup is much like being a tester. You design, prioritise and run tests, to learn, discover and explore.
These four takeaways are why we are building a tech startup for testers.
Because that is who we are.
<<Read more from the Start-up Series>>
About Simon
Co-founder of Qeek, the SaaS product for testers, Simon grew quality-obsessed technology teams at Rightmove and Gumtree/eBay. Head of community at Croydon Tech City, Simon understands the growing needs of the startup community. An experienced agile coach, helping teams to realise their potential, Simon draws creativity and joy from performing as a musician.
