Wednesday, 17 February 2016

Completing the Product Feedback Lifecycle

I started my first job with a product vendor in 2010, almost immediately I started to provide feedback to the Product Management team as I used the internal Alpha and Beta versions of our product. Almost immediately I wondered if my efforts to improve our product were heard or even mattered - I rarely got feedback on my suggestions and more rarely did they make it to production.

In all the companies I've worked for, I believe the Product Managers genuinely cared about, and worked hard to produce a great product. And all of them were swamped by a long list of feature requests and finite resources to manage and deliver them.

In the middle of 2013 Google decided to refresh their Maps product. Google sent me (and probably millions of others) an email asking if I wanted to participate in the beta release. I’m a sucker for new and shiny so I signed up.

Joining the New Maps beta program

At the time I was using Google Maps on a near daily basis, usually to find accommodation for business trips, my habit was to enter the address of the customer I would be visiting and the use the “Search Nearby” feature to find a hotel.

The first time I tried to use the new Google Maps to do this, I couldn’t find the “Search Nearby” button anywhere. New and shiny instantly became incredibly frustrating… So I hit the feedback button and let Google know that they had removed a feature I relied on heavily. I got a nice auto response email from them thanking me for my feedback and then I got on with my life - I thought that was the end of the process.

Fast forward a few months and I got another email from Google as new Maps became generally available. They referred to my feature suggestion and told me that thanks to my (and many other folks, I’m sure) feedback, Search Nearby was in the new Maps! They also included instructions on how to find and use it.
"Search nearby" is back!

That experience changed how I view the feedback button on Google products, I now know that my little voice does get heard by the big company. I’m far more likely to offer feedback to Google than other companies who have never responded to my suggestions, even if they did implement what I had suggested.

Product Managers rarely dream up great new features in isolation, and I’m no different. Our customers and staff often have the best ideas to improve our product. Reflecting on my interaction with the Google Maps Product Team, I know how impactful it can be to ‘close the loop’ with anyone who takes the time to offer a suggestion about how to improve our product. I don’t have fancy tools to automate the process like Google does, but a direct email or phone call works just as well (maybe better).

Whenever I receive a feature request, I always track who made the request so that I can go back to them when their feature is implemented (or when it isn’t, but that’s a story for another post).


Customers who engage with Product Management, and know their opinion is heard and valued are well on their way to becoming loyal fans and advocates as they begin to feel some “ownership” of the product which they’ve helped build (I love telling people about the Search Nearby in Google Maps – it’s my feature!)

Closing the loop with customers who give product suggestions and feedback takes time, and there is never enough time for all the tasks on my list, but I think keeping customers informed from 'feedback received' to 'release delivered' is time very well spent. And once you've been around the loop once, don't stop there, ask the customer for further feedback on what you've delivered for them.

In my experience, most Product Managers don't close the loop - it's easy to do, but easier not to do... I'm sure they mean to and believe it's important, but suddenly the day is over and that didn't get done. That's unfortunate, because when I close the loop I am able to do my job better, I enjoy it more, and customers give great feedback about me to other people in the company. 

What are your thoughts on closing the loop? Do you do it? Why or why not? How do you do it? I'd love to hear how to make this process easier! Please sound off in the comments.

Tuesday, 16 July 2013

How to Run Tests After Build in Visual Studio 2012 Professional

One of the great features of Visual Studio 2012 that gets blogged about a lot is the option to run all your tests automatically after you build your project. If you’ve read about this feature and went looking under the Test menu for the option to turn it on, you may have been disappointed to find it’s not there. I know I was.

Many blog posts and tutorials don’t mention that this option isn’t available unless you have VS 2012 Premium or Ultimate. I’m running Professional, so no special sauce for me.

I want to Run Tests After Build, but I only have VS 2012 Professional…

Yeah, it seems to me like most folks out there aren’t running VS 2012 Ultimate, but many of us want to use this feature. There are several third party tools which will let you do this like NCrunch, which does continuous testing while you code. But that is a paid tool, and you may not have budget for it, or you may have to use the tools given to you by your employer.

Scott Hanselman occasionally says that the compiler is the first unit test, and I would often find myself hitting the F6 key in VS 2012 to build my solution, just to make sure it did.

When I started to get serious about testing I began to use the “Run All” link in Test Explorer frequently.

RunAllTestExplorer

That button saves any modified files, builds the solution (equivalent of F6) and then runs all my tests. Pretty good, except it means a trip to the mouse. I was missing the simple efficiency of pressing F6 and getting a result quickly.

It turns out there is a keyboard “shortcut” to Run All, it’s Ctrl-R, A. I think it’s quicker to use the mouse…

Remapping keys in Visual Studio 2012

After 6 or 8 months of clicking and wishing I had Visual Studio Ultimate, I realised that keyboard shortcuts in Visual Studio are fully customisable. Shortly after I decided to remap my F6 key to the Run All command in Test Explorer.

You can read how to do this on MSDN.

Here is the result:

VSOptionsKeyboardRemapF6

When you do this, the Build command gets moved to Ctrl+Shift+B.

VSOptionsKeyboardBuild

Before I remapped my F6 key, I used to keep Test Explorer hidden down the left side of the main window. I figured I didn’t need to see it, except when I was running tests which was done with the mouse. One change I made to my window layout is to make the Test Explorer window always visible (now it’s at the bottom of the screen) so that I can see if there are any failed tests after I press F6.

FailedTest

Conclusion

It’s not as cool or easy as just ticking a box like all the folks with Ultimate, but if you are looking for a free and easy way to run all tests at build, remapping your F6 key is a good way to go.

One shortcoming of this suggestion is that if you use the menu to build your solution, your tests don’t get run, but I can live with that.

Happy coding (and testing)!