Chapter I – The Product Vision
What to expect
The plan here is to document the events that unfold as I get ready to form a product team, and pass on a vision, which I believe would take wings with an Agile process in place.
Blockers and queries are bound to come in and you get the answers at the same pace that I unravel them myself ☺
Chapter I – The Product Vision
So I had this great idea at hand and had been mulling over it for years. Eventually, its time to get it transformed into a working product.
Now with the adrenaline rush that came in with this decision, I wanted to get things moving at a quick pace and quickly moved on to send a google meeting invitation to a group of developers that sprang into my mind. What I envisioned was that, I could call them all in, announce my product idea, let them know that they were the choice team and get it all going in an hour flat!
Big rookie mistake.
Now thankfully, as the invitation was being created and people added, I saw myself in the meeting, explaining about my product. In my mind, the idea was out there in 2-3 sentences, and me looking around at a dumbstruck team, with a stupid proud smile on my face.
Was that how I wanted to present my perfect idea? Certainly not!
So quickly closing out of the invitation window, I took a few minutes to think over the below points:
-
So I believe it is a great idea, good. But have I dived in deep and thought about the whole business prospect?
-
Has the idea been given enough thought to decide on the kind of skills required in my team?
-
Have I thought through an air tight product idea or are there areas where I would like suggestions from others?
-
Most importantly, has the first main release been thought through, or the MVP (minimum viable product)?
Naturally all the above questions screamed out a big NO.
After this bit of introspection, I sat down to sketch out my product vision and attempted to tie the loose ends. Having my idea drawn out in pen and paper, for one, restored the belief that the idea was indeed a novel one. Additionally my thoughts could also be pointed to the intrinsic details of the user flows.
This little activity helped me realize what my most important goal was. It was to make sure that the user interface would be immensely user friendly and attractive and would aim to take away all common pain points of a user. An imaginative UX/UI inspired designer was a definite requirement in my team.
The resulting sketch on the chart roughly displayed the product idea, though it was a far cry from an artistic point of view. This was going to serve as a base for the team I selected, to have the first introduction meet before plunging into development. So now, an invitation was sent to a set of team members whom I now knew was necessary for the product vision. The team comprised of,
a) 1 Scrum master
b) 1 tester
c) 1 UI/UX resource
d) 2 developers
e) And one Business Analyst/ Proxy Product Owner.
Now even though a “proxy” product owner is mentioned, in reality he/ she would be a co product owner. Iam aware that this completely goes against the Scrum principle of having a single product owner so as to avoid having different product views. But I wanted to try this out and my reasons for trying this was
a) The co product owner selected was a Scrum certified product owner and was a good choice as a team coach too.
b) My availability was limited.
b) I was open to having a partner to aid me in defining my product vision.
Even though Scrum is strictly against a co product owner, would it not be great if we could actually share a same vision and keep passing on the same idea to our team members? So if this works out, our team would never face a scenario where information is delayed, as it was certain that 1 product owner would be available anyway.
So I am curious myself to find how this goes as preparations are on for my first meeting with the co product owner and then with the whole team.
Stay tuned for the next chapter!
Pingback: How sure are we that our MVP is both viable and valuable to our users? | Bridge Blog