3 ways software product managers can work effectively with development teams

November 29, 2009 7 Comments

As a software product manager, I spend a lot of time working with my development team in making sure that they are well aware of the customer pain points and the requirements of the solution we are trying to build. I have heard from time to time from my colleagues and also from software product managers in the community as to how development team does whatever they want without paying too much attention to the market requirements. While it is true that development does embark on some “skunk-work” or their “sandbox” projects, I have been lucky enough to have my product development teams more in tune with the market research my product management teams have done.

Here are some tips on how you can make sure your development team stays tuned in to the market needs and builds very simple, easy to use products that will delight your customers.Software product manager

1) Involve the development team early – One of the common complaints I have heard from my developer friends is how their product managers do not get them the actionable information they need about customer needs. Go figure! We as software product managers think that development teams want to do whatever they want and the developers are complaining that we are not getting them the information they need. Guess how developers find solace? They start writing code. When they have written enough code to solve the customer problem they perceived to be right, you as a software product manager stepping in with market information is of no use. Here is one of my common mantras to anyone who cares to listen – “Developer resistance to a software product manager is directly proportional to the number of lines of code written.” More code they have written, less chance you have to influence them and get anything changed. And guess what ships – what was written.

So how can you mitigate this problem? Involve the development team early. Trust me there is no time called “too early” to involve your development team. Involve them even when things are fuzzy so that they can start asking you all the questions to which you have to find answers. Make it a collaborative process. Set expectations that you do not have all the answers yet. This puts their skin in the game – it builds a sense of ownership. Product ownership can do wonders. Before you realize, everyone is rowing in the same direction and everyone wants to win by building the right thing. I am yet to meet a developer who wants to create a product that will fail. Yes, there are developers who want to build the pie in the sky solution that only they will use, but you are bound to find such people in every profession including product management. There is nothing you can do to prevent the occasional “skunk work” or “sandbox” projects – but if this is the norm at the place you work, it can only be one of two things – you are not doing your job as a software product manager or you are working for the wrong company. This is because with such state of affairs, market failure can only be a corner away.

2) Be a good strategist, but more importantly be an excellent tactician – Set a good product strategy that will help your company achieve business success. But make sure you remain involved in the execution of your development process. You as a software product manager need to know exactly where the development team stands on your product on a daily basis. You need to know of every bottleneck or hurdle faced by your development team and your job should be to find a way to resolve these issues. This in my perspective is one of the greatest reasons why Agile product development methodology is so successful – every team member is on the same page every day and there are no unpleasant surprises.

Being involved at the execution level will help you build a great rapport with your development team – it has for me. It sends the message that you care about the success of the product and that you are in the trenches with the development team.

3) Be the team’s cheer leader - Being a developer is not a fun job – it is a very stressful job. I won’t be able to do it. Every product development cycle has its ups and downs. Be the cheer leader for your team during these ups and downs. This may mean that you get your team the beer of the week from the nearest micro brewery or you take them out for lunch or dinner once a quarter. Always keep the human perspective – it is not all about work.

Take every opportunity to make sure you stand up for your development team. If your executive management team wants you to give them a briefing on the progress of the development effort, team up with your development lead to do the briefing. If you are going on a customer visit or going to be on a conference call with your customers, invite your development team to accompany you or listen in if appropriate. More you bring them up to speed on the customer’s needs, less battles you have to fight on the problems the product has to solve.

Don’t try to hog the limelight – it is not all about you. It is all about the team. After all your customer really does not care who is getting the internal limelight or who came up with the solution. The only yardstick for the customer is if your company can solve his painpoint with a very elegant solution.

Thoughts? What are your key learnings on how best to work with your development teams?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of Bealonghorn.utexas.edu

Filed under product management

6 “bootstrapping” tools for software product manager

November 19, 2009 12 Comments

You are a software product manager trying to start a software company on your own. Or you work for a startup or a small software company and don’t have much money to spend. But you still need to design a good user experience, do early usability testing with your prospects, do a quick show and tell of your ideas to your management, your customers or potential investors. Here are 6 “bootstrapping” tools that I have used a whole lot to communicate and collaborate without denting my wallet too much.

1) SnagIt – When doing wireframes or mockups, you want to steal UI ideas from different websites you see – you want something quick and dirty to show your product development team or your customers to get some early feedback. SnagIt is one heck of a tool that comes to the rescue. It is super easy to use and helps you capture images from your screen and edit it quickly. Cost: $50

2) Balsamiq – An outstanding, super easy to use tool for creating early wireframes. I am a very visual thinker and need to draw when trying to communicate user experience ideas. This is the best tool I have used to quickly create some quick and dirty wireframes. The wireframes look hand-drawn so your management team or your customers do not think you have it all coded and ready to ship. The palette that is available is exhaustive including the very nice interface elements for developing wireframes of iPhone apps. Cost: $79

3) Google docs – Need to write functional specs? How about revenue modeling or what if product pricing analysis? Google docs works very well. Its collaborative ability where users can markup documents and can compare the different revisions is good enough. You will not find everything Microsoft Office has, but it has a lot of the things that you commonly use (except Pivot tables – can do via Gadgets, but painful to use). But then beggars cannot be choosers. If you don’t have money to pay for the expensive MS office ($149.95 for Home edition per user) and need most of the features that one commonly uses, Google docs does the trick. Plus it is all online and everyone is working off one copy of the document. Nice! I personally have not used the presentation functionality and hence cannot comment how useful it is. Cost: $0

4) Goto Meeting – So you have created the mockups and want to do some quick usability tests with your customers and prospects and none of them are local. You want to do web conferencing for free? Goto Meeting is my favorite tool. So easy to use and works like a charm everytime. In the hundreds of times I have used it, there were only 2 instances where the customer could not use it because of firewall issues on their end. Though it is a little expensive to use, it is something where I would spend the money so that you can easily collaborate via web conferencing. Cost: $49/month or $468/year

5) Skype – Do I need to say anything about this popular FREE tool? I use Skype in conjunction with Goto Meeting so that I get free phone calls. The only thing you need to make sure is that the folks at the other end also have a Skype account. You can get your team members to create an account, but with customers or prospects you may have to use Goto Meeting’s audio. Cost: $0

6) Gmail – Again, want free email without having to shell out money for MS Outlook? Cost: $0

Overall, total fixed cost = $129, recurring cost = $49/month for GotoMeeting.

I am sure there are many more tools out there that one can use. What do other software product managers use? Please let me know.

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of GuyKawasaki.com

Filed under product management

Customer Visit: 2 creative ways to get a budget

November 8, 2009 1 Comment

Times are tough, budgets are being cut, there is a travel ban in companies, so as a product manager, how do you get a travel budget so that you can get out of your office for on-site customer visits? It is hard, but here are two creative ways you can make it work.Getting budget for customer visit

1) Think local - It is one thing to walk into your boss’s office and try to convince him/her that you have to fly to Hawaii to do an on-site customer visit. More eyebrows will be raised out of suspicion of your desires, no matter how relevant your product is to the Aloha market. It is a totally different and easy sell, if you want to ask permission from your boss to visit your local customers. Do you have customers within a 75-mile radius of your office that you could visit. If yes, what are you waiting for? If not, do you have any within a 200 mile radius that you could drive to? Yes, it could take 3-4 hours to drive to get there, but by announcing that you are a creative boot-strapper and that you are willing to even drive 3 hours to better understand customer needs, your management will very likely appreciate your initiative. Day-trips are cheap because there are no hotel stays, no expensive dinners or flights involved. Even in companies where travel budgets are tight, I am sure there is still a few hundred dollars to support a product manager’s day trip to a customer site. And if there isn’t, then your company probably does not believe in building products that are in-tune with customer needs or might be in deeper financial trouble than you think and you should start looking for a new job.

2) Piggyback - Are you scheduled to travel for any trade shows? In which case, most of your travel expense is already a sunk cost. Do you have any customers at or near the place where the tradeshow is going to be held? If yes, extend your stay for a day or two and visit those customers. The incremental cost to do this will not be much and approvals are easier to get. Piggyback on that planned trip to do customer visits. Are you going to go on a personal vacation, traveling for a wedding? Is it possible for you to extend your stay for a couple of days and mix in some business as part of your trip? If yes, ask the company to pick up the tab for your extended stay. Get creative and make sure your management knows that you are going over and beyond what is expected of you, to make sure that the products you build are in-tune with customer needs. It is such employees who will be valued the most when push comes to shove.

Does this make sense? How have you managed to do a customer visit during the tough economic times?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of piperreport.com

Filed under customer visits, voice of the customer

What is product simplicity?

November 3, 2009 2 Comments

The KISS principle – Keep it simple stupid – something all of us as software product managers have heard one time or another. But when it comes to products, what exactly is prproductcomplexityoduct simplicity? Product usability and simplicity typically falls into three different categories, in my perspective. This perspective is based on my 13 year experience as a software product manager building products for the mass market – small businesses in particular. Enterprise products may be a different ball game and hence your mileage may vary.

1) Less is more – Don’t overload your product with all the features your users may ever want. Instead focus on those features that 80% of your customers would need. Yes, this will mean telling the remaining 20% one of two things – this product is not for you (sales – yes, be honest with the customer) or get used to the feature set we have because here are the benefits. In the latter case, here are couple of examples that come to mind: Apple iPod comes to mind. I would love to delete songs directly from my iPod, but I cannot. I need to go to iTunes for that. I can choose to complain that Apple was wrong, but given the huge other benefits offered by the iTunes-iPod integration, I get used to it not being there. Apple drew the line in the sand and said No.

One of the common pitfalls companies fall into is full product configurability. Full configurability is not necessary. What it does is create a slew of options, intimidates users and on top of it creates a maintenance and testing nightmare. Majority of the users tend to use products in the default configuration. How often have you gone to the preferences or options dialog to configure something, especially when you are a brand new user? Provide basic configurations and then let the customers guide you with the other configuration options they would need. Again, stick to the 80% rule.

This is hard to do because the 20% of those customers who need all of the complicated features could be your largest customers, the most vociferous ones. But as a software product manager, you should own your product direction and learn to say No to those requests which will take your product in a direction you don’t want to go. I do not mean be arrogant, but reason with the customer as to why you don’t want to do it – in the past, I have been very honest with the customers as to how the general user base would not need the functionality being requested and they have backed down. The trick here is that your product should have such a high value proposition that these things end up to be gravy in the whole scheme of things. And if the features requests (which fail the 80% test) are the meat and potatoes for these customers. then your product after all may not be the right fit for them. Be honest with such customers and recommend the products they should look at – this may even be your competitor’s products. Don’t miss out on building the relationship, you would never know when it will come handy – for all you know they may find the competitor’s product complex/expensive and may dproduct simplicityecide to buy your product instead.

2) Your product behaves the way users expect it to – In this case, it is not about less features. Often, users expect the product to have the functionality to get their job done. To facilitate this, your product could end up being feature rich. But there is a difference – there are many products that are feature rich but not very user friendly. Then there are other products that are equally feature rich, but much easier to use. Personally, I was involved in one such product called SolidWorks which made its mark because of its production readiness and because of its ability to run on Windows with the same ease of use as Office applications at 1/5th the price of PTC’s product called Pro/ENGINEER. Pro/ENGINEER was powerful, super complex to use, ran on Unix workstations and costs tens of thousands of dollars at that time.

The trick here is to minimize the deviation between how the user expects to complete a particular task and how the software allows the user to do the task. Larger the deviation, lower the usability of the product. This is because users will have to learn new ways to do tasks that they think should be very easy to do. Usability testing is key to ensure that there is minimal deviation between the user expectation and actual difficulty in completing a particular task.

3) Your product is a game changer – Your product comes up with a very innovative way to do things the users could never imagine possible with the current systems he uses. Two products that are classic examples are 1) Bose products and 2) Shazam, the nice little iPhone app.

waveradio-shazamWhether it is Bose’s Wave radio or the acoustic noise reducing headphones or the iPod sounddock they sell, their products are game changers. They have hidden all the dials/controls that the user had to muddle with to listen to music and  made it dead simple – no dials, no controls, it just works. This to me is a game changer. Shazam is equally simple. It listens to the music that is being played, analyzes it and identifies the song – number of clicks needed – ONE to start the process. It even integrates with iTunes to download the song. To top it all, it is FREE. Can it get any better than that?

You can do this, it takes effort. When it comes to software, this is easier to do (or at least I think it is because all I have done is software in my career). One technique I have used successfully is to write down each and every step that is currently involved in completing a task and see how many of these can be automated or compressed into less number of tasks. You will be surprised in what you find. But when doing this, you will come across the naysayers who ask you – “What if the user wants to do this, what if they want to do that?”. The best way to counter is by making sure you know what the 80% of your users will need and then stick to the principle of Less is more.

Thoughts? What have you as a software product manager experienced when it comes to product simplicity?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Images: Courtesy of gizmodo.com, bose.com, shazam.com

Filed under product usability

Follow

Get every new post delivered to your Inbox.

Join 176 other followers