by ·0 Comments

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.

Continue reading

by ·0 Comments

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.

Continue reading

by ·1 Comment

As a Product Manager, I often describe what I do falls into 4 or so buckets:

  1. Strategy:
    1. High-level: Where should the product be going?
    2. Low-Level: What is the next thing we should build that will help us get closer to our goals/target?
  2. Execution:
    1. Discovery: What is the exact problem are we trying to solve and what is the outcome we want to achieve?
    2. Delivery: How do we build this solution we “discovered” during the Discovery phase?
  3. Analysis: Did what we design and build during the Execution Phase solve our users problems and bring us closer to our goals? Why or why not?
  4. Support: How can I help the rest of the organization? This includes working with Customer Success to help them understand the inner workings of new features/processes, and working with Marketing to educate our customers on these new features/processes.

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:

  1. I am not taking credit for coming up with any of these processes. Some were in place when I arrived while some I helped shape.
  2. These version numbers are arbitrary in a way; I grouped certain things together depending on when I started at a new company or when we found a process that worked for some timeframe.

Not sure what Discovery is or what some more detail, take a quick look at this post before continuing.

Let’s jump in:

Continue reading

by ·0 Comments

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:

  1. Understand what the problem is and validate it (Problem Discovery)
  2. Understand what the right solution is and validate it (Solution Discovery)

Let’s look at what these two entail:

Continue reading

by ·0 Comments

If this blog was a river, it seems to be drying up. But please, don’t jump to any conclusions. It’s not as if I just started this blog and kept it going for a couple of months for the sole purpose that it would help me find a new job, and then slowly abandon it….well actually it does seem I did that didn’t it?

Well, let me explain.

It’s been a busy two months! How busy? Well, I feel like I’ve I’ve accomplished more in the last two months than in my previous 2.5ish years in Product Management…so yeah, it’s been nuts. So crazy that I’m writing the draft of this blog post on a plane…that’s a first for me.

But wait, let me back up a bit..

Continue reading

by ·0 Comments

Why do people use your product or your competitor’s product? In essence, they are trying to get a job done. But what is a job? Let’s take a look at, for good reason, the most used example: the drill vs. the hole.

Do I need a hole or do I need a drill bit?

 

 

As Harvard’s Marketing Prof. Theodore Levitt famously said:

“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”

Mind blowing, isn’t it?

Nobody buys a product or service for their features, they buy it for their benefits or for the job they wanted solved. This reasoning was what helped me to grow from an average salesperson at Staples to one of the best performing…while I was in high school! I remember when I first started at Staples, I used to sell printers based on their features, often telling customers that Printer A could print 22ppm (pages per minute), but Printer B could print at 30ppm, but they didn’t care and chose Printer A because of its price. Once I learned that I should instead talk about how Printer B could get you back to your life sooner, then people started to cared. Nobody wanted to sit there and watch the printer print paper, they wanted their print job to be finished quickly so they could staple/bind it, and move on to the next thing.

This reasoning was what helped me to grow from an average salesperson at Staples to one of the best performing…while I was in high school! I remember when I first started at Staples, I used to sell printers based on their features.  I used to tell potential customers that Printer A could print 22ppm (pages per minute), but Printer B could print at 30ppm, but they didn’t care about ppms, just the cost. Once I learned that I should instead talk about how Printer B could get you back to your life sooner, then people started caring. Nobody wanted to sit there and watch the printer print, they wanted their print job to be done asap so they could staple/bind it, and move on to the next thing in their lives.

Sadly, I forgot this key learning while in university, but luckily got reminded about it and learned more about it through a framework calledJobs to be Done (JTBD) at, coincidently, the New York Jobs To Be Done Meetup. They more I learned about it, the more I felt it was undervalued in the world of marketing, and most importantly, in the world of product development.

Let’s look at how Jobs to be Done can help your product be the best for its customers.

Continue reading

by ·17 Comments

I attended a talk by Natalie Hollier back in September on Lean Product Management for Enterprises: The Art of Known Unknowns, when I saw a slide from her presentation that blew my mind.

It wasn’t that the slide had beautiful visuals or fancy transition effects, but what it had was a simplicity on how it communicated on a high level the differences between the 3 most common product development processes: Waterfall, Agile and Lean.

This image/slide was so great, I had to ask Natalie for it, and luckily she sent it to me asap!

Without further adieu, here it is…
Continue reading