The last few months have been challenging and formative. There have been many mistakes and lessons learned. It has become clear that our initial vision for a 2-product Seeking Sigma is no longer feasible.
Reasons:
Bandwidth limitation - SimplePayments and SS initially relied on completely different GTM strategies and we don’t have the internal capacity to support this.
Message dilution - I only have one personal brand and we barely have enough credibility as it is to chase one ICP. Going after 2 is suicide.
Friction in the sales motion - More friction in sales is never good and adding multiple products and pricing tiers for customers to consider hurts us greatly.
Teaching before doing - Building training material is time-consuming and opens the door to productive procrastination. Instead, we need to narrow our focus on what we’re doing for ourselves, take action and document for our internal use case.
Moving forward it is clear that we need to align on one product, one ICP, one price and one value proposition.
Lessons To Take Stock Of:
The product development roadmap needs to be agile and defined by user stories - shipping versions without sufficient user demand is costly and futile.
There needs to be a high degree of ownership & trust - one person must own the GTM function and trust the other to own the product function, end-to-end.
Ship more scrappy products - The paralysis of chasing perfection is real and slowed us down greatly. Let’s just ship and break things.
Know your ICP by name - We greatly overlooked the importance of building for and writing marketing material with a single persona you have in mind. You must know this person personally and have a relationship with them.
Prioritise where your time goes - In the beginning, more than 30% of your time in the calendar must be spent talking to customers.
Pick a single GTM strategy - I now know that there are many x-led growth strategies out there and they all work but for different businesses. We must assess and pick 1 and then go all in on getting it to work before looking elsewhere.
Keep the stack simple - We need to be as profitable as possible and as simple as possible. Always choose the simplest option.
Write to plan - The bias towards taking action without taking the time to document and develop a brief before starting takes more time in the long run. It’s not enough to make a few Figma scribbles, ideas must be fleshed out in a thoughtful memo.
With these lessons, we are wiser and more formidable as we start the iteration loop again to build the next version of Seeking Sigma.
Here are the steps I believe we need to take for a successful pivot:
Before We Can Work, We Need To Know How We Work:
It’s essential here that we don’t over-engineer and create more complexity than what is required. Remember, simplicity is a feature.
Firstly, we need to define clear roles and get everyone fully on board the ship. The waters are likely to be extremely turbulent and treacherous moving forward. If anyone is only half in, we’ll sink. If we don’t fully trust each other to perform their role without oversight, we’ll sink. If we’re not individually working on becoming elite at what we do, we’ll sink. Everyone must have skin in the game.
All work should build up to KPIs which build up to initiatives (OKRs) which we take responsibility for every quarter. This forces us to align around what outcome we are trying to drive with our work and prevents “doing tasks just for the sake of it”
The entire company must be prioritised around maintaining double-digit growth week-on-week for our north star metric. This forces focus on what moves the needle.
We need to be diligent with how we use Asana to implement our cycles: We agree on x points per person per week so that we never deliver under our potential but also don’t burn out. Daily stand-ups to ensure alignment and consistent start times. Post-cycle reviews every Sunday to avoid duplicating mistakes. Plan the next cycle every Sunday.
User feedback, bugs and stories must be stored and then systematically arranged based on impact and effort. Nothing gets built until the feature has been properly drafted as a user story. This eliminates any confusion around the use case and ensures we are building with a customer in mind that we can reach out to for clarity if needed.
Developers are full stack and own the entire dev-test-launch-bug workflow themselves.
No project can be started until it is fully scoped out and a tangible deliverable has been mapped.
A WBR (weekly business review) is conducted with leadership where: Statuses on OKRs are updated, internal metrics and the north-star metric are reviewed.
Everyone in the business must: Talk to users + make content.
My Proposed OKRs:
Simplified Structure = 1 OKR per person per quarter. 3 key results per Objective. Starting 3Q24.
Our 1st priority is to clean up the existing mess of tasks, ideas and user feedback which is in different formats and scattered across different systems.
Speaking To Customers Has No Requirements:
We cannot repeat the same mistake as before and build in isolation. A working product is not a requirement for posting content and talking to users. When you speak to users, the product builds itself.
Defining The New Product Vision:
It makes sense to be strategic and build in an area we already understand (revenue generation) and utilise as much of the previous codebase we’ve built as possible.
I still believe that a multi-product approach is the best economic model because it enables great expansion (cross-sell) opportunities which are the cornerstone of profitability + it increases stickiness (through lock-in) + it enables us to go after different buyer personas (struggling with different issues) and draw them into the ecosystem. Having said this, I recognise the importance of first “doing things that don’t scale” and respecting our limitations. We’re not the only ones to face this issue, Monday.com did as well and I suggest we follow their proven playbook. They initially marketed themselves as “WorkOS” - one unified platform. They achieved PMF and scale before then breaking their platform into different products and sucking up all the extra cash on the table.
We will do the same by building: The OS that the next generation of revenue teams run on.
Why revenue generation is our target function:
Being close to where the money is made always means we are fired last and hired first.
Every business wants more revenue which makes our value proposition easy.
Why B2B SaaS is our target vertical:
By solving a problem for ourselves first, we eliminate a lot of niche research and we can be our first case study
I already know lots of founders/companies to reach out to in this ICP
Why London is our target market:
Timezone restrictions
Within Europe, I still believe it is the centre of SAAS startups
I’ve underestimated the importance of meeting customers in person before and won’t do it again - the team is based here so it makes the most sense.
Conclusively, it makes sense to be strategic and build around an area we already understand (revenue generation) and utilise as much of the previous codebase we’ve built as possible.
The 3rd priority is therefore to write a thesis presenting the initial market problem we want to solve and the solution we envision for it. This will consist of:
Market analysis and research
Defining user personas
Establishing a value proposition
Outlining core features and functionalities (based on JTBD framework)
^ Most of this has already been done through our iteration of SS 1.0 and SimplePayments. We now just need to unify it all together into a coherent platform.
The initial vision and feature set are somewhat broad based on the vastness of the function we are targeting and the legacy of a vast arrangement of different customers from SS/SimplePayments. I suggest we focus down by solving our problems first.
What do we need ourselves as a B2B SAAS startup in the revenue team?
What can we build that repurposes the code we already have as much as possible?
The initial MVP will be focused on just 3 core user stories (features). I will be the ‘customer’ requesting these user stories to solve my problems but all future development will be based on external feature requests.
The 4th priority is therefore to define the initial 3 features and write in-depth user stories for them.
Development Timeline, Budgeting & Resource Allocation:
I think we should aim to have the initial MVP up and running within 2 weeks provided all the designs are provided ahead of time.
The 5th priority is to launch this MVP on product hunt and get it in the hands of users ASAP so we can start collecting feature requests.
Develop A GTM Strategy:
There are several ‘x’-led growth strategies out there which all have different pros and cons. We’ll need to evaluate them individually and make a decision but I do already know that initially our strategy will consist of:
Founder-led growth:
LinkedIn
X
Product hunt community
ICP slack communities
Multi-channel sales-led growth
Email
X / LinkedIn
Conducting demos
Manually onboarding customers to understand their needs
Offering professional services to provide cashflow to support further growth
AppSumo launch to get an influx of users to build a better product
YC cross-sell opportunity
^ The 6th priority is to create refined strategies for each of these, make a decision on which strategy we are going to implement and define our pricing at the start.
