Product Roadmap – Ask for Directions!

Posted on by Lior Bachar

As a product manager, you are expected to to balance between the day to day “Tactical” role and the long term thinking of the strategy of the product. This is not an easy task to juggle. Sometimes the day to day gets the best of you and between supplying your team with the appropriate product requirements and running the product backlog you might find yourself without time to figure out the game plan for long term.  

In a product role we must understand the purpose of the product, not just the short term feature set that we are making for this important client who said that he will leave if we wouldn’t make it. It’s really easy to fade away with small and easy to plan features that will take the product one step forward. But, if you are a good navigator, you know that it needs to be a step towards the strategy and not just a random feature that will set you back with more requests and push the product backwards.  

A good PM should always think about the directions. Every sprint needs to push the product towards the goal – the Core problem that the product is solving. If it’s not part of the big solution, it’s simply not interesting, no matter how much that customer wants that small fix (unless it really makes sense to make and it will take less than a day with QA).

The RoadMap is the most important document you will ever use and ideally produce, however, it’s not an easy task create such a plan. You will spend a lot of time to make it and probably more to modify it.That doesn’t mean that you shouldn’t spend that time on making it and follow it. The best advice that I can give is to ask for directions, not just your CEO, everyone! It will amaze you who will give you the best advice, the best focus points, what your product is missing, what is working well and what is filled with bugs. You should ask your customers, they are paying for the product and should be an important part of decisions but that’s not enough, ask prospecting customers, ask the support team, ask customer success and post sale team, ask the sales team, QA, design, just ASK. Some people feel that too many opinions can lead to bad options but in the case of the roadmap the more you hear is the more you learn. True, some users will only say that they want faster horses but most will tell you the parts that will make them upgrade and pay more.

In order to make sure that the RoadMap gets the appropriate attention and to see that their is a correlation between tactics and strategy, make sure that you set some time every week to go over the roadmap and see that you are on the right route.  

Road to production – Product Manager Pre-Launch To-Dos

Posted on by Lior Bachar

In the typical product life-cycle, the product manager has to adapt to the different phases of the product, from definition to development to production to maintenance. this post will suggest actions on one of the most critical points in the life-cycle – the sprints before going live to production with a new product. Fortunately I had the opportunity to accompany products in the last phase of development, both in a small startup and in a big company. The road to production can be very long, it’s up to the PM to make sure the road is as short as possible, here are my notes.

  1. Velocity is the key – Like in any sprint, velocity is a key ingredient is the success of the product launch, it is really important to manage it, in a startup it’s the way to manage burn-rate and investors expectations, in a big company, the date you will set for the launch will stick to you more than your name, if the product will fail to launch you can lose your credibility with your business partners and that’s a hard thing to recover from. my tip here is to increase velocity check ups in the last sprint to once a day, rondeau with the R&D chief and QA unofficially by the end of each day to make sure you know what and how to prioritize in the daily meeting the next day. Know all the bugs and make sure that only mission critical bugs are taken care of, leave the rest for post launch.
  2. Requirements – Although you reviewed the business logic with the team a number of times, and it’s all written down in the PRD and explained perfectly with flowcharts and scenarios, Do it again. The previous times you reviewed the business logic with the dev-team was probably before they coded, it’s amazing to see how things can be lost in translation in the development cycle and lose touch with the main reason why we are developing the product – its revenue source. My tip here is to go over the logic at least two times, make sure everybody is onboard and understand the revenue stream, especially the QA whose main responsibility is to limit to none the surprises in production – He is a key person to help you deliver the product as expected.
  3. Bugs – QA is one of the most important stakeholder to the delivery process, one of the problems is that most QA people I worked with tend to seek perfection, in the launch day the product is not perfect, we will find hiccups in production probably and that’s ok, as long as we can fix it in time, it is really important to make sure that only show-stoppers, mission critical bugs are in the sprint and all the rest – from minor to major, are put aside for later, the time will come and if it’s not critical just let it be.
  4. Team Spirit – The team has been working very hard to get the product on time and in most cases did overtime and put their all in this product. Although it’s not your direct role to keep them happy, make sure the feel your appreciation, keep telling them the importance of going live and making revenues, it will help, trust me.
  5. Integrations – in some cases, your product will need to integrate in an existing product or service from another part of the company, this can be a problem, even a big one if not planned right, my tip here is to plan the integrations as soon as possible, make sure you have a physical design that both sides agree on, and Gantt your way into the critical points knowing that every setback will be a huge risk.
  6. What’s next? – even if the roadmap is not neatly planned, It is more important to have the product out than to work on next iterations. In most cases the first post-launch sprint will be mainly around making the system more stable and fixing bugs, you will have time to work on the next version soon enough, focus on the real important thing – going live.
  7. Risks – the list above is basically a list of risks and my tips on how to mitigate it. The last tip and probably the most important one is to identify the risks in your road to production and make sure you know how to mitigate them, even if, god forbid, the launch will delay, you will know how and what needs to be done to get on route as soon as possible.

To conclude, the Road to Production can be long and painful, but it can be fun and joyful, If you want to be fully prepare my best tip is to do this list of tasks along the way. Don’t wait for the last sprint to get closure, get it done along the way and you will see that the last sprint will be as joyful as the rest, just make sure you pack well and enjoy the ride.

Tools for Disruption: the Product Manager’s ToolBox

Posted on by Lior Bachar

As a Product manager, you are required to use all sorts of tools in order to deliver requirements, learn the market and at the end of the day, manage the Product. All the products that I will list are part of my day to day routine and ones that I fully recommend. In general you will find here Online tools that makes me more productive, focused, and well, focused on being productive. Something you will not find here is Email as I think it’s the worlds biggest waste of time. Please feel free to leave comments and share any great tools you have discovered yourself.

Asana – Asana changed my life, I am not kidding, I have been trying for a long time to adopt a GTD life style, I used all sorts of products that didn’t give me exactly what I need and didn’t help me get things done, instead, they made me work for them. Well that all changed when I met Asana. And to add a cherry on top of this productive cake, the team I work with uses asana as well, making it even sweeter.

The way I use Asana is pretty straightforward. I look at each task as a  “thing” after it’s added to my tasks (usually from my iPhone), I then prioritize them in “My task” and follow up on it every day. I perform a daily review before the Daily standup meeting (aka scrum meeting) and a weekly review at the end of the week.

I use the “projects” as sprintboards and manage a backlog project where all my crazy ideas go to rest before I bring them back up. For me Asana is the best tool I use to manage everything in my professional life and the results are amazing.

The best thing about Asana is that they offer so many integrations so if I want to use a Gantt chart I use Instagantt and it integrates right into Asana, I also integrated Slack and Wuffo (more on that to come).

The only issue I have encountered is when passing the stories to the developers using Asana and it’s support for the full development cycle. Thats why they are working with TFS, to keep Asana my tool I use zapier to transfer items from Asana to TFS.

I also like: Axosoft (Ontimenow), Any.do, Jira and Trello.

UXpin – I think I have tried every mockup tool in the market. I was pretty happy with Balsamiq when my boss told me to try UXpin, A small startup from poland. Since I love trying new tools I tried it and fell in love. It has some hiccups but its manageable. The best feature for me is the live preview. I can share a link with my team/users/management and receive comments straight on the page while showing them the exact user journey I want the user to go through. I always like to pull this trick in a review meeting when I get a comment and fix it while people are still talking and it fixes in the live preview – now thats pretty cool. UXpin is especially great with the front end developers taking the Bootstrap like design and implementing it with little hassle. I think that UXpin is the perfect combination of what a PM needs for mockups and UX to design and development.

I also like: Balsamiq, Axure, Invision (more for presentations).

LucidChart – For a long time I used presentation tools to create flowcharts It was simple and useful until I started to use Lucidchart. Lucidchart is one of my favorites tools and companies, Simple to use and just a really smart tool that will illustrate a flow better than 1000 words. It too has a way to present and share with colleagues to gather comments, developers love using it for Physical design and it’s great to collaborate on it. I use it also to create mind maps, sequence diagrams, ERDs and even for mockups.

I also like – MindMeister (just for mind mapping)

Apple Pages – PMs need to write documents, a lot of documents. It’s really important to find some editor that is useful to you and others. I admit that for a long time I used MS Word, but that era is over with the new Apple Pages online tools. Since I use a Mac, MS office is not a good option (nor wanted), and my organization doesn’t rely on Google Apps for it’s office needs, I use Apple Pages online for collaborative docs and exports PDFs when I am done with a document. Apple has a long way to go before it will be as good as Google Docs but its good enough for me and the Continuity with my idevices is great.

Keynote – Unlike Pages, Keynote is the best presentation tool I have ever used. I have been doing all my presentations using keynote for a long time and it’s an amazing yet simple to use tool. It has everything I need in order to deliver a great presentation with great themes, transitions and design elements. Like Pages the continuity and Icloud makes it even better.

Slack – I don’t think I can say anything new about slack, the tech unicorn that is about to rule the IM products. I specifically love using the Channel feature to talk about sprints, areas of development (SDK for example) and it’s integration with almost everything (Asana, TFS and RSS are my favorites). Unfortunately most of my colleagues use Skype, so I must keep two online. Can someone make a Skype integration to Slack 🙂

Wuffo – PMs need to collect user data and sometimes forms are the best way to understand what your users think they want. Wuffo is great for that and much more, I use it to survey users, ask leading questions about roadmap features and even for a ticketing system. Simple to use/edit and integrates to Asana and Slack.

Productive bites – I want to share some tools that I think help me to be more productive:

Popclip – Amazing add on for mac users, I use it a lot for fast translations, cut copy and paste and all sorts of other integrations.

Dropbox – You have to keep all these PDFs stored somewhere.

Zapier – Zap all these tools together. (IFTTT is also awesome)

Rescuetime – I love to learn how productive I am and Rescuetime is just for that. It monitors your computer activity and gives you a productivity score – I try to stay above 80%.

Buffer – Great to manage tweets, shares and make sure I promote this blog enough.

Ghostery – Find out who and what is running on a website.

BuiltWith – Find out how and with what this site is build with.

Flycut – Best clipboard tool I have found.

To sum up – All these tools are useless without a PM behind the wheel. Use them wisely and feel free to share comments for more tips and tricks.

The Do’s and Do’s of Product Management

Posted on by Lior Bachar

The first thing you need to know in order to be a great product manager is that you have to do. Doing things is not as trivial as it sounds. As a product manager, you are going to be measured based on deliverables – the products you manage. You start at the product planning at the very beginning of the development cycle – before the designer creates any design, before the developer writes the code and before the  QA makes sure that it’s working properly. Think about this cycle and then add to it the most important factor –  the end user who is supposed to be “delighted” and help us generate revenues.

So what do we do in order to..do? First we do our best to ensure that we expressed what we want the deliverable to be and left minimal room for interpretations. In order to achieve this, make a clear mockup that shows exactly what you want, design a flowchart to show exactly what journey the user will go through and write a clear, simple PRD that explains every detail.

We are not done yet, actually we are only in the beginning of the Do-Chain – after you have everything you need to be delivered and are confident in your vision, review it with the team and then fix it. Remember, one of the reasons to review it is to “buy-in” your team. Once everyone is on board it’s smooth sailing… not!

As a product manager you are responsible for the product’s success, not the product development or launch. Think about the “mini-CEO” analogy, the CEO needs to drive value to the companies shareholders, the PM needs to drive value through the product. That makes us responsible for everything, not just the PRD. The requirements as good as can be, are nothing without delivering a product that generates value. Thats why we need to make sure along the way that we are on route to success.

So, What do we do? Never blink, keep track of everything that is product related, make sure the developers have everything they need, think about the next versions, make sure the customers are “accepting” the product, think about the next features and prioritize the roadmap.

I once heard someone say that after the PRD is written the Product manager is left with nothing to do. The truth is that we never stop doing, we always have something to do, something to research, something to perfect. So keep on doing!

Why 2015 will look and feel different.

Posted on by Lior Bachar

2015 is the best year to be a product manager. It’s the year that UX will be much more important than any bit or byte. Wanna know why? (keep reading…)

Let’s start with a quiz. Pick up your phone (the smart one), scan all your apps, find your favorite most often used apps. Now think – does this app have a real life equivalent? Is this app just making a process better and faster? Or does it really change the core experience?

Assuming you didn’t choose Candy crash (or any other game for that matter) the answer is – Holy s**t, all the apps I use are just a better process to the same procedure in the offline world. Let me walk you through it – Email – thats easy – people used mail since writing was invented, even CC is named after Carbon Copy – that carbon paper that would copy everything you write to a paper under that carbon paper (BCC stands for blind carbon copy) email is the same process we are used to, just faster, easier and more efficient. How about instagram – Making photos look better and sharing it? did someone say 1960 scrapbook? Whatsapp – Remember how we use to throw small pieces of paper to our friends at school? Snapchat? remember how we asked our friends to destroy it after? you get the point – everything we do online is just a better way to do something we used to do offline.

Assuming this is right, what’s so different now? The answer is hidden in history. In the 1980s the PC was introduced to humanity. In the beginning no one thought that it will be in every home by 2000 and in every pocket by 2015. What was the biggest challenge? Experience. The Mac changed everything we know because of the introduction of the graphical user interface (GUI) and the Mouse and keyboard. That invention allowed a big portion of society to use the computer and start advantage of its benefits.

In the late 1990 internet started a whole new revolution, the combination between the internet and the computer as the interface started a new chapter in the way we do stuff, from communicating to gaining knowledge, the internet changed it all.

The growth was rapid, the Holy Trinity (screen, keyboard and mouse) helped humanity reach different levels of knowledge. The experience was becoming better – chips became faster and cheaper and the computer became a commodity.

In 2007 The next revolution of the internet experience was introduced by the iPhone, The iPhone did change everything, first of all it changed the experience how we consume the internet, then it changed everything else. In iPhone OS 1.0 (iOS was introduced later) everything was based on the concept of Skeuomorph look and feel, it means that all the apps looked and felt like their lifelike equivalent – Notes looked like yellow notepads, reminders looked like a list of tasks you hang on the fridge, the calendar had the same look as a real life calendar and so on.

So, what does all this history have to do with the fact that 2015 will be awesome for Product managers? It took apple 7 years to change the premise of skeuomorph to Flat design. Since September 2013 (when iOS 7 was released) people need to change the way they use their phone. It wasn’t that big of a change, but it really was. The experience revolution has began and now we can take it to the next step.

The latest Mary meeker report clearly stated that bad UI is dead. In 2014 Google changed its design strategy moving to material design. The users are ready for the better, more advanced experience. The game is changing again, it’s time to take advantage of this change in conception and take the experience to the next level. Think about the possibilities that wearable technologies are giving us, the Holy Trinity will change in 2015 – goodbye screen, keyboard and mouse – say hello to screen finger and gestures. Add to that the watch, phone, glasses, tablet and laptop and think about all the possibilities to take something we always did, and make it better.

That is why 2015 will be the year where experience will matter more than looks, it will change the way we do things, it will make it smarter and faster. We will make it better.

The secret of running a marathon with Sprints.

Posted on by Lior Bachar

In Agile product management we run neverending marathons. The roadmap is our way to plan the path of 42.195 kilometers iteration. The roadmap is a great tool, an abstract plan that will indefenetly change along the way. The road is long and the finish line is just a blurry timestamp with no real directions on a map. Careful or you might end up running with no cause.

Product managers are a part of this neverending marathon. If your run ended it means that your product died and you have failed. So a product manager needs to maintain the best shape possible at all times. And while we see this run as “neverending”, others see it as a marathon with one clear goal – Launch. Product managers plan the roadmap- sure it has a starting point but we know that if successful it will never end, it will just improve….we will run faster, smarter and more efficiently, driving business and revenues to new records quarter after quarter.

The main reason for uncertainty in planning the roadmap is the business landscape, it’s changing and at a fast pace. If we want our product to be successful (which we do) we need to be able to constantly adapt to the everchanging landscape. Personally I “check the pulse” of the business once a day. in one heartbeat we can miss a tectonic change that will make my product obsolete.

In order to gain traction and “start running”, we need to keep the process up to date, step by step. How do we do this? With Sprints. Sprints have a lot of technological purposes that can and should be done even without a product manager in the team. They help to clarify the plan and short term goals and can be measured and improved over time. The case for sprints is clear, we need them, if we want to get things done. Running a sprint is hard, it requires a lot of effort from the team, laser focused effort.

In general – Minimum viable product (MVP) is the best way to start planning the road map. Know what’s your near future goals are before the run. Don’t start before you know what you want to achieve in version 1, Viable is the key word here.  I see the MVP as version 0.5, it should be halfway to a product you feel is valid. Remember what Reid Hoffman, Founder of LinkedIn said: “If You’re Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late”

Sprints are a good way to run a business oriented product in the modern age. Just remember that they are a part of a bigger picture, a  longer run… the neverending marathon and improvement along the way is key. My tip (based on a famous quote of Krembo from Mivtza Savta) “You start as fast as you can, and very slowly you increase the pace”. The secret is to always know and plan the next step, if the next step is accurate – you will never stop running.

Interpretations – Product manager’s achilles heel

Posted on by Lior Bachar

One of the most important skills to have as a product manager is great communication. Most people understand this skill as being a “People Person”, someone with great interpersonal skills. Although this is true, the real bread and butter of product management lies in sending clear definitions and specs to the developers. Sure, they can like you and you can like them but that will not create a better product, it will just make communicating easier.

The way to make sure the product is focused on the business goals and features that affect the bottom line is to ensure that the business requirements meet the technological solution. How do you do this? Deliver a spec with limited place for interpretation.

In theory, product managers meet the “demand”- sometimes we even create it. In a way, everything is in our heads, but our job is put everything in writing, writing that is clear. This means that everything starts in our imagination. We can use creative tools (mockups, wireframes, and other user stories) to help realize our imaginations. Let’s simplify this process: we meet the customer. We understand his needs. We convert his needs into technology.

Now, Imagination by definition is “the ability to form new images and sensations in the mind that are not perceived through senses such as sight, hearing, or other senses.”  I think its more fitting to imagine a better definition of “Imagination”, one that helps to better define our process as product managers. Perhaps there are stages to this imagination, and if there are, then the stage right before imagination becomes defined requires special attention. In order to meet the business goals, specifications need to be clear enough for developers and only when this is met do we create real value.

Now – What is the “KPI” for “clear enough” to developers – In my experience it is to minimize room for interpretation. When a developer/TL gets a feature you want to make sure that the dish will taste exactly how the chef described it, not a second over or undercooked. In product development, we create the recipes, developers, as “chefs” then take our recipes and make delicious dishes out of them. Can you tell I am hungry while writing this?

So, How do we minimise interpretations? Share. Yup, it’s that simple. Share your thoughts and be open to comments (basic product management). Once you share – the backfire will help you perfect your product – the questions you will be asked will represent the”unclear” areas – open to interpretation – things that need to be perfected.

Who should you talk to? All of the stakeholders that would care about this feature. If they are happy, you are happy. Share it with the developers, they might see things that you didn’t think about. Share it with your clients – if in house, go over the process until you are confident in the solution. Share it with the QA – they will stamp the product, in their heads (at least the good ones) are all the edge cases that you did not think about, QA needs to know your acceptance criteria and what are core values is in the feature.

To make the process efficient and not to waste too much time, set up a review meeting and come prepared – show your work and hear comments. Make sure all the stakeholders are on board and when the meeting is over – all of them are on the same page.

Remember the cold rule of design flaws – the sooner you find the flaw, the less time it will take to fix it. We are responsible to find it as soon as we can and we do so by limiting the interpretation. So now I ask you, did this post leave room for interpretation?

Who, What, Why – The Product language

Posted on by Lior Bachar

Product management is an art. It’s inception in the best way. It requires you to “play”, so to speak, with Business people, Developers and Managers in order to get the best results.

To make it work, a Product manager needs the right tools. Some people refer to Product Managers as the translator between business and tech and vice versa – I would like to challenge this idea and say that we are creating a new language – the User Language, or when translated into English, it’s known as the..User Language (yes, it’s Universal).

User stories are one of the best tools to explain to everyone what you want and it’s pretty easy. All it requires is for you to state Who you are, What you want to do and (really important) Why you want this to happen.

Let’s put this in context – “As a Product manager, I want to write a blog in order to share my product ideas and insights”, wow that sounds just like me! What are the chances.

Lets  break down this story further- Who – The first thing you want to explain is who you are – so the reader, whoever they may be, will understand the context theyare reading. What – What do you want, what needs to happen?, what is the main problem you are solving with this feature? Why – If you want something done, explain the reason for it, what drives you to do it? Is it to make money? If so, explain – a developer will work much harder on features which he understands the impact of on the business that this will bring. And the business owner will understand what needs to be done in order to reach these business goals.

Product people solve problems, ‘User stories’ is our language to explain how we solve them. With any problem, there are bigger and smaller parts, so make sure to start with an “EPIC” – the main story you want to share. The EPIC  is what drives all the other stories below it. Consider this blog’s EPIC story; “As a Product manager, I want to write a blog in order to share my product ideas and insights” now, Let’s approved with stakeholders (I approved). After that start to think about other stakeholders and write their stories (example):

  • “As a blog reader, I want to read a blog about product management in order to learn more about what and how product managers work.” – that sounds like you!

Now we need to break this down to operational tasks. It’s easier when you know what needs to happen:

    • Tasks:
      • Get a domain.
      • Choose a blogging platform.
      • Think about interesting topics.
      • Set aside time to write it down.

User stories can get even more complicated.. speaking as a machine, explaining though specs how to solve simple business objects..but more on that in the future.

Next time you begin to tell the story of your product- Tell a User Story. Not only will it make everything easier but it will also make the next steps much more clear.