Recently, I got a chance to start a business with an old friend of mine. We went for ten months before I realized that particularly business was not the right for me.
In those ten months, I learned quite a lot, and it gave me proof that I have the stomach to handle the intense startup roller coaster. There were definitely some dark days…
Here’s what I learned from my “failed startup experience:”
When I co-founded IT Werks, I was coming in as the product and marketing guy, and because we had no outside investment, I would only get paid when we closed new clients. My partner has been B2B sales for the past ten years, but we also needed to invest heavily in the development of our product, which he was far better suited than I was.
In other words, I would be the sole breadwinner for the team.
Last time I was in a sales-focused role was between 2004 – 2007, when I was an “Electronic Sales Associate” as Staples and still in high school.
Surprisingly (or maybe not), I was crushing that role and trained new hires who were often older than me in how to sell. I did well because I was honest with my customers, I refused to hustle people and make them pay for things they didn’t need, and I could simplify complex technology into simple terms to help them understand what they needed and that they didn’t. Apparently, I was so good that some of my customers tried to get me involved in their pyramid schemes so they could get richer…even at 16, I couldn’t fall for that crap.
Shift forward nine years later, time to get into sales again. This time, in a B2B role working with small business owners.
But this time, I was failing miserably…
These series of posts are based on my recent experience with starting a startup, and how I went about it with my partner to get us both on the same page for us to develop a strategy we both believe in and can execute on.
If you’ve been following my posts, at this point you know why you’re doing this, who is your ideal customer and target market, and what problems you want to solve for them.
And you’re probably demanding when are we going to start building a solution, because you already have a solution in mind, or have even started building one. So in this post, we’ll start looking at what we need in our solution.
But first…we need something: your value proposition.
These series of posts are based on my recent experience with starting a startup, and how I went about it with my partner to get us both on the same page for us to develop a strategy we both believe in and can execute on.
Previously, we spoke about how to nail down your target audience and as a next step to do some customer development/interviewing to understand if your profile was accurate, and start understanding their problems and their needs.
Why not jump into building some solution if we know who are customers are? Our customers have hundreds and hundreds of problems, and so to ensure we don’t spend our time solving the wrong problem, we need to spend some time doing customer interviews to learn and validate their most significant problems, and then build a product around those problems and needs.
Such a focus will help increase your product’s chance of success.
Now that you have spoken to 10-15 customers about their lives and problems, you should have a decent list of issues. Here’s what we want to do now:
These series of posts are based on my recent experience with starting a startup, and how I went about it with my partner to get us both on the same page for us to develop a strategy we both believe in and can execute on.
In my last post, we spoke about the importance of having a Why and one way you can discover your Why. Remember, the more personal the Why is to you, the more powerful it can be for you.
Chances are, you already have identified a product and a market you want to target. I don’t blame you; that’s how we work. We jump straight to solutions, but we need to take a step back to spend a bit more time defining and researching our strategy to increase the chances of our startup’s success. A little more work now will pay a thousand times over and over in the near future and far future. Defining and understand your customer will allow you to understand their problems since you are now focusing on a narrow range of people, and now you can design/build a solution that solves their problems perfectly.
Let’s dig into how we can define and understand our target audience.
These series of posts are based on my recent experience with starting a startup, and how I went about it with my partner to get us both on the same page for us to develop a strategy we both believe in and can execute on.
I bet you know what you want to do.
I bet you know how you want to do it.
But do you know why you want to do it?
Why are you willing to put your reputation on the line? Why are you willing to put your career on the line? Why are you willing to alienate yourself from your friends and family during tough times by working nights and weekends with the hope this thing gets off the ground and makes a dent in the universe?
There’s only one answer to these questions: the why.
As a Product Manager, I often describe what I do falls into 4 or so buckets:
I strongly believe that a Product Manager who cannot execute is not a Product Manager. You may have the great ideas/strategy but if you cannot work with your product team to validate the idea, build it and ship it, then what’s the point of having all these great ideas?!
I also believe that we’ve greatly improved our Delivery Process over the last 10-20 years. We now use some version of Agile with Scrum, Kanban, Sprint Planning meetings, etc. to break things up for the Engineering team, and most organizations deliver on at least a weekly basis or are hopefully moving to Continuous Integration and/or Continuous Integration.
The Analysis aspect is also easier than before. We can use services like MixPanel, Kissmetrics, and Amplitude to see what actions our users are doing, then create dashboards to understand trends using Periscope and Chartio.
What I’ve felt we’ve not yet effectively conquered as a disciple/profession are the Strategy and Discovery aspects, which are the most critical for any tech team since they help you avoid building crap.
Strategy is something I’ve recently started diving deep into so at this time I do not have a strong viewpoint to share, but I can share with you on how my Discovery process has changed over the last 3.5 years of being a Product Manager.
Couple things to note before we continue:
Not sure what Discovery is or what some more detail, take a quick look at this post before continuing.
Let’s jump in:
Discovery is a process we use as product people to better understand the problems we are trying to solve for the customers we are trying to solve the problems for. It also helps us ensure that it is the right problem for us to concentrate on since there are always a million other problems we need to be solving at any given moment. My understanding of Discovery is mostly influenced by Marty Cagan, who walked me through the concept during of his “How To Create Products Customers Love” workshops. (highly recommended!).
In Discovery, we want to do two things:
Let’s look at what these two entail:
I was recently talking to Europe-based FinTech startup who were looking to hire their first Product Manager (PM), and they wanted this potential PM to be based in New York (NYC) rather than in Europe with the rest of the company. Their rationale was logical: the majority of their current and potential clients are in the US, particularly in NYC since they operate in the Financial realm, and they wanted that PM to be as close to their customers as possible.
This situation got me thinking that they have three potential options:
Ideally, the entire company should relocate to where the majority of its customers are, especially since the company is quite small at its stage.
Relocating the company would provide two enormous benefits:
But let’s say, for some reason, relocating the company (Option B) is out of the question. Should the startup continue as plan and hire an NYC-based PM so that the PM is close to their customers (Option A), or should they hire a Europe-based PM to that the PM is close to the product team?
Based on my experience, I would strongly recommend hiring a Europe-based PM and here’s why:
In my last post, I explained how Intercom is such a wonderful tool and makes my life as a product manager easier by making the following tasks straightforward:
But, as I use Intercom more and more, I’m starting to realize there are certain limitations Intercom has (either by design or not), and I need to get around them somehow…
Here’s how Intercom is breaking for me: