I used to have "great" ideas, on crafting impactful products for the society. But, everything started to mess up differently with my imagination when I started executing them. It's been a blindly struggling journey, where my direction was led by feelings and biased predictions, rather then lean and scientific processes.
"It was a waste of time" - I thought after looking back everything I have done to support my teams executing those ideas, even now when I'm writing these lines. And the very trigger for that thought and also my blog today is this amazing PM course.
Mistakes help we learn, and I'm sharing mine with you today.
Ideas are easy. Execution is everything. - John Doerr
1. The rush into the development phase
A problem well-stated is a problem half solved. - Charles F. Kettering
That 3 months after graduating from high-school is one of the most impactful periods on my life, when I had a chance to join a NPO project. An interesting side story of that journey is that I was assigned as a leader of the Program Team, who was the only male, and also, the youngest member. I grown a little bit more afterwards. Realizing the importance of those types of activities in students' life, I had an idea of a website where students can find and apply projects within which their admins can monitor.
The idea sounds great, at least to me.
My team and I crazily developed the "MVP" for 3 months, and release it out. The response of the users?
"I can do my work fine without this".
Though the experience is relevant and somewhat necessary for the students, project admins didn't find it really useful for them. And that was the failure of not paying effort in really understanding user and discovering the real job to be done, from the admins' perspective.
In other words, I skipped the Discovery phase, and jumped right into the Delivery phase, without testing the Desirability of the whole idea.
2. Completely wrong mindset about MVP
It wasn't that I don't try to test product ideas. I did have the intension to do so, with the "MVP", but my assumption on it's definition, was wrong.
Me: "We want to know if the users really need our product. We'll need to code it up in a raw and ugly but enough-feature version then give it to our users".
MVP is not like that:
"The Minimum-Viable-Product (MVP) is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort" - Eric Ries
Well, 3 months is not really called "least effort".
The reason why I realized I was wrong about the MVP mindset, is that "it needs to be a runnable product" a.k.a "a coded website". And it shouldn't have had to be, which otherwise did waste a lot of valuable time producing little valuable outcome.
A nice example of the solution for an MVP is the Dropbox initial MVP video . Drew Houston, the founder, just recorded a video to demo the features when they didn't really have a runnable software ready for use. The customers reacted positively, and just that validation was powerful enough to give the team a fundamental belief that this would work.
Base on these theories above, we can think about solutions to test out the customer experience before spending any effort in development, which needs strongly validated propositions and costs a large amount of time.
3. User Story (Map) solo
At the very beginning of starting out with 2 projects 4 months ago with my team, I literally laid out all the stories by myself, and the same process continued later on when "I" discovered we needed to added more features.
The problem here is "I".
Solo creating the stories myself and just handing out the design and Acceptance Criteria to my Dev Team created 2 problems:
Dev Team won't understand the stories until we discuss them in the Sprint Planning. Hence, I became a bottleneck in the process
As we didn't have a shared understanding of the product pieces we had to build, Dev Team, who is the absolutely experienced than a Product Owner (me), could not grasp the whole flow of the product, couldn't help me when I felt struggled in the design and workaround for technical side of the product. If I had onboarded the developers together to lay out all the stories in all the epics, we would have saved a great amount of time discussing and solving our product problems.
Another piece of knowledge I learnt about Story Mapping is that I should have focused on prioritizing stories with full user flow. For example:
If the product has a user flow like: Searching -> Selecting -> Purchasing, we should prioritize the stories so that combining them together will help users achieve that full flow, rather than just focus on all the stories of one column (Search/Select/Purchase).
Thank you for reading this thing. I hope some of these retro on my journey of learning Product Management gives you - the readers - some useful knowledge in the field.
I'm addicted to feedbacks, so please feel free to comment some below. Tell everyone what you think!
Such an informative post!