Words, mocks, working product

That’s the order in which you can create delight when you are talking about a feature to your customer/prospect. Mock screens trump words and working product trumps mocks.

Photo by Headway on Unsplash

If you show your prospects/customers a slide deck about the feature you are not gonna impress them, that should be the last resort. Mocks are one step better than words, at least then your customers can see how the end product is gonna look like, you might be describing a elegant horse and she might be imagining a donkey! Without the mocks the customer is not gonna understand the value well. With mocks, at least you got them to see what you have envisioned, this also helps you validate the user flow that you thought was the right one. The best conversations with the customer, which will deliver delight, is by showing a working product, it could just be a beta activated in your account.

Having said that, if you want to validate something quick, then mocks are the right middle ground between you describing the feature with just slides or words and going the whole 9 yards to build out the entire feature just to get validation.

Another lesson I learnt this week, was when you are talking to a prospect, always keep showing how the value is delivered in the product even as you talk about different value propositions in the product.

Product Manager. Who is this.

product manager

Recently I had a conversation with a friend of mine and he asked me what I do. I said I am a product manager and he wanted to know what exactly I do. That is when I started pondering on the question. Leaving aside the many definitions that already exist, I wanted to write my own, derived from what I do.

When it comes to product, he is responsible for the product that is, the product that will be and draws insights from the product that was. He keeps a close watch on what is being developed now, prioritizing and clarifying any doubts developers or designers might have with current tasks. He sets the vision for the product and breaks them down to short-term goals. He ships, iterates, ships, iterates…

When it comes to users, the product manager is an advocate of the user. He has to know what is best for the user and not just act on the user’s requests. As DHH recently wrote “acting on customers’ requests, rather than on their behalf, is generally a bad idea.” He can only act on the user’s behalf if he truly understands the user and that comes by going through support queries, through user interaction and through data. Asking “why” helps.

When it comes to writing a spec/PRD, he ensures that he covers majority of the use cases and willingly adds (of course, after some thought) new use cases when suggested by someone else. He writes in a way that developers easily understand, defining any new terms that is not in their lexicon. He defines metrics to be tracked for each of the features or enhancements. He points out the dependency, if any, with other teams or developers.

When it comes to stakeholders, he keeps them posted on the progress his team has achieved. He becomes the single point of contact because stakeholders trust him and are comfortable talking to him. He shares metrics to show progress or success of features launched.

When it comes to roles, he juggles between being a mentor, problem-solver, manual tester, story teller and user advocate.

When it comes to sharing knowledge, he is generous.

When it comes to credits, he channels them to his team. When it comes to failures, he takes responsibility, learns from them and gets to work immediately to correct the wrongs.

As a person, he is persuasive and not manipulative. He is able to back his ideas and suggestions with reason & data. He is curious and willing to learn.