Successfully organizing your pivots as a startup
Our journey in figuring out how to pivot in a meaningful way.
The Problem
One of the most difficult parts of running a startup is being able to successfully separate your own bias from what the customer wants & what the market will accept. This is most dangerous when you can’t recognize exactly where your bias came from & so it acts as ungrounded instinct – which is easily mistaken as experience – and it can be a trap.
The simplest examples of this is startups that offer developer tools. Sometimes these startups can be very successful – like JIRA, which is successfully used as a project management tool by many companies. But often you get into a place where you begin to think that since you’re an engineer & the customer is an engineer, that must mean that what you want is what the customer wants. This often leads startups to find a poor product-market fit.
In our early days as a startup, we’ve found ourselves in a similar area. As we progress to have more conversations with our customers & conduct more industry analysis to better understand our competitors, some of the information about the industry becomes unorganized bias. When we work towards our product vision, this often interferes negatively. Though we’re able to quickly determine what needs to be done, we’ve had difficulty remembering why.
The First Solution
For instance, when updating your feature set, it’s very easy to accidentally include features aimed at different customer segments. This is dangerous since instead of creating a complete product for one customer, you’ll end up creating half a product for two customers & value for no one.
One thing we quickly realized is that a pivot isn’t always a huge change in market accompanied with an article in the WSJ.
Startups pivot every time they decide on a new feature set, to tackle a new customer segment, or release a new product.
Depending on the stage of your startup, this might be weekly, quarterly, or annually. But change is important to the success of any startup.
However, change always comes with a cost and so over-changing & changing to the wrong direction can be detrimental to your business. By now, we’ve become victim to both at least once.
We’ve found that the biggest driver of over-changing for us was attempting to think of what troubles we might encounter a few months down the line. But often the picture changes so much in those few months through working with your users that you end up finding a solution to your possible problem – or it turns out that you actually can’t see the future and so you never encounter it. By then, you’ve already wasted your time thinking about a hypothetical issue & spent valuable resources trying to scale without actually starting on your product. Sometimes it’s okay not to have a plan – as long as you have a plan to have a plan.
As for the wrong direction, this tends to happen when we focus all of our time on answering the ‘what’ questions for our product but not enough time on ‘why’.
Some of our most productive conversations have occurred when we’ve actively forced each other to think of the ‘why’ every time we have an idea. This forces us to not only envision the destination of our product but also the route to get there. But forcing ourselves to always think of ‘why’s is very important.
What it boils down to is really best said by Sheldon Cooper from The Big Bang Theory:
If our friend, the flag, has taught me anything, it’s to go where the wind takes you. As long as you remain firmly attached to a rigid pole.
For startups, that rigid pole should be the real conversations you have with your target customers. But you should be able to flow with the wind as the market evolves & user experiences change.
Problem->Solution->Delivery
What we wanted was to rethink our ‘Product Vision’ document so that it would allow us to change rapidly while making sure that we avoid the trap of moving in the wrong direction. To do this, we actually scraped our product vision document and instead came up with a new tool to organize our vision.
As a joke, we’ve been calling it the ‘P(T)SD’ document because it helps us to keep our past conversations uncomfortably close to our future. What it stands for is ‘Problem-Solution-Delivery’ – which is an attempt to separate our vision into three distinct categories of thought.
Problem
The first is the problem. This acts as the root of all other ideas & is grounded heavily in the conversations we have for customer validation as well as with professionals in the industry. Information recorded in this category is required to come with justification from real conversations, the specific customer segment that it affects, and the dollar value of the pain it causes.
All problems recorded here are agnostic to our actual business. We use this section to record all information we come across – even information that we might not have a conclusive use for yet. But regardless of its current use to the business, it helps us get a more clear picture of the state of the market & allows us to easily figure out what is the most valuable issues for us to tackle from both a profitability and necessity perspective.
Solution
This is perhaps where we are attempting to do something a bit unorthodox. We’ve begun to separate our product’s solutions from our delivery strategy. We don’t envision our product to be the solution to the market’s problems. We discuss solutions in an abstract form.
Solutions are required to reference at least one problem and provide concrete justification as to why the solution is ideal for the highlighted problem & its customer segment. A solution would highlight an idea such as: “in order to solve the problem of low quality candidates on job boards, we should follow the recruitment pattern of targeting passive candidates instead of active candidates.”
This quick summary provides the reader with a snapshot of the solution & some backing as to why it might be a good idea. A strong solution would then go on to explain why passive candidates have a higher quality and reference a few conversations in which this tip was given to us.
Delivery
The delivery mechanism is part 2 of the solution. This is where the actual details of the product live.
The delivery references multiple solutions and provides justification as to why the proposed delivery mechanisms are ideal for the customer segment & will efficiently deliver the solution. It should also define the cost of implementing the delivery.
Why this helps us
The interesting thing is that by separating the solution from its delivery, we’re able to ensure that the majority of our pivot discussions are focused around alternative delivery mechanisms. This is because we’re able to pick a well validated problem & solution pair and then figure out why particular delivery mechanisms are less successful then others.
This helps keep our conversations moving in the right direction. It also minimizes the cost of change as we know that feature changes are mostly a technical cost. Meanwhile changes to solutions would require more validation and be paid from the business development perspective.
An example of this is the Apple vs. Google directions of AI-driven technology. Both companies are trying to address the same problem: how do we dynamically augment user experiences to personalize the experience for each user. Both companies have also selected the same solution to this problem: data-driven machine learning which would change user experience based on the user’s data. However, both companies envision different delivery mechanisms for their business – and therefore are in different markets with different products.
Google thinks that the best way forward is heavily centralized data processing which provides them with certain advantages such as more precise predictions in a shorter period of time.
Meanwhile Apple is moving in a different direction with their delivery. Though they agree on the solution, Apple is also attempting to tackle the issue of user privacy. In order to include both solutions, the delivery they are working towards is the advancement of localized AI.
Conclusion
Separating yourself from your startup is a tough job for a co-founder — it’s hard to figure out where your personal experience is useful vs. where your personal bias is harmful. We’re hoping that this new document is going to help us with our journey navigating through these problems and we hope it’ll help you too! If you have any tips for us from your own startup experience, please do share! We love learning from others.
