- Posted by Justin on September 29, 2008
Great post on lack of complaints not equaling success. I have seen lots of developers think this way only to be proven wrong later when they are struggling with user adoption.
Taken from: Lack of complaints does not equal success : How To Be A Good Product Manager: Product management tips
If you want to be a bad product manager, assume that lack of complaints means your product is successful. There are lots of customers using your product, so when you add a new feature or make a change and don’t hear complaints, that must mean that everything is working fine. If something was really unusable or broken or didn’t meet your customers’ needs, they would let you know. It’s much easier to just make a change or add something to the product and wait to hear feedback than to do a whole bunch of research and testing first — that’s just a waste of time, right?
If you want to be a good product manager, proactively seek out feedback rather than wait for complaints. Lack of complaints does not mean that you have a fantastic product — it just means that you are not getting any complaints.
Waiting for customers to complain is problematic for several reasons:
- Not all customers complain. Think about all of the products you use on a daily basis, and the problems you encounter with all of them. There may be a confusing button on your cell phone, a strange error message on your online banking site, or a slippery grip on a kitchen gadget. How many times have you taken it upon yourself to contact the organization responsible for that product? Despite the multitude of different ways to complain — from the traditional methods like contacting the company directly, to more modern methods of voicing your frustration on Twitter or a product review site — most customers do not make the effort to send this feedback directly or indirectly to the company. A product manager simply hoping to hear from customers with problems is only going to hear about a fraction of the problems from only a fraction of the customers. For every customer who vocally complains, there are likely tens or hundreds or thousands of others who are silent.
- Lack of complaints may mean lack of customers or users. While we would like to think that lack of feedback means lack of problems, it is often that lack of feedback means lack of experience on which to provide feedback. When a product manager adds a new feature to a product and does not hear any complaints about the feature, he may assume that the feature is a success and the fact that customer service has not received any complaints is because it is working smoothly. Unfortunately, it could be just as likely that no one is using the new feature, and thus no one has any experience about which to complain. If there are a small number of customers using the new feature, relying on their complaints alone may provide very skewed feedback.
- By the time someone complains, it is usually too late. While the previous two points are worth noting, this is truly the most important reason to not simply wait for complaints. For physical products, changes to a product after it is in the market can be extremely expensive and time consuming to rectify. From a purely financial standpoint, it is the responsibility of a product manager to attempt to produce the best product and thus avoid costly changes. However, even for web-based products which can be changed very quickly and cheaply, waiting for customers to complain is backwards approach to product development. Sure, it may be gratifying on the surface to say that you are able to respond quickly to problems that customers raise, but wouldn’t it be better to prevent these problems in the first place? Would you rather buy a car from a company who listens to your complaints and reacts when your car has problems, or would you rather buy a car from a company who produces a car which will not cause you problems and will not cause you to have to complain?
Ultimately, no matter how hard an organization tries to address problems and meet needs, people will complain, and product managers can benefit from listening to and understanding those complaints. However, when a legitimate complaint is lodged, rather than just reacting to it, product managers should ask, “How did we not know about this earlier?” Is the complaint related to something that the team should have known about? Would a better understanding of the customer needs have helped prevent it? Would better design or more usability testing have uncovered the underlying problem? Did a defect make its way into the final product? Did we know about the problem and just hope that no one would notice? How did it come to this — that a customer had to complain in order for us to realize something was not right?
Complaints are a valuable source of information which can be used to help improve your product, though they are only one source and should be used carefully. Product managers need to be proactive at gathering feedback from customers and prospects, though activities like usability testing, Win/Loss analysis, site visits, observational interviews, and other types of qualitative and quantitative research. Rather than just waiting for complaints and responding to them, product managers need to be focused on preventing them from occurring and getting to the root cause when they do appear.
- Posted by justin on September 10, 2007
I know, I know people tend to hate post about what you are going to post on. For months I have had a back log of stuff that I wanted to post about but I just could not find the time to write the post or just plan didn't make it a priority. I have been trying to figure out how to fix this problem and have been reading a bunch of stuff lately on prioritization. One of the suggestions was to write down what you wanted to do and advertise it to others so that you are some what held accountable.
In the past I have pretty much strictly focused on the software development on my blog but I am planning on expanding the scope to include other stuff such as music, drumming, and media center that I am interested in. Sticking to strictly software development post I believe has hindered my desire to continually post.
Thing I want to post about:
- Synergy 2
- Utilities that I am using
- VMRCPlus
- LINQ (I am planning on creating some kind of sample app so that I can start playing with it.)
- Media Center Utilities / Add-Ins
- xbox360 MCE Extender
- MediaMonkey
- Drumming (Drumsets, Drummers I like, Instructional Material, etc)
- Music I am listening to lately. I have found some cool new albums that I need to post about.
- Posted by justin on September 10, 2007
Sorry it has been so long since I have posted anything. Things has been pretty crazy that past several months. Look for several post of next few weeks.
To get thing started again I updated to dasBlog 2.0 and changed my theme. As part of the theme change I add the "post on this page" and blog roll sections to the right side navigation.
- Posted by justin on February 7, 2007
Channel 9 has a pretty cool video on the patterns and practice lab and how they set it up to enable the agile development that they do. I would love to have a setup like this. The workspace looked fairly fun to work in.
http://channel9.msdn.com/Showpost.aspx?postid=238321
- Posted by justin on January 31, 2007
I have to say that I completely agree with the blog post below. I have experienced many developers that could code but were not good developers.
Original Blog Post From: http://codebetter.com/blogs/jeremy.miller/archive/2007/01/31/Being-a-Better-Programmer.aspx
There's a flurry of great posts and comment discussions going on right now about the divide between good developers and bad developers
The Great Divide
Like Jeff Atwood, I do believe there is an almost binary switch between effective and ineffective developers. I'm not exactly sure why this is, but if you'll indulge me, I've got a couple pet theories:
- People that are good coders are able to do make code work faster, which leads to getting more experience than their slower , and spare more thought cycles for how to do things better next time. The innately talented developer is able to get better and faster each time, which gives him or her more time to invest in getting better. From there I think it's simply a snowball effect.
- To Phil Haack's point that it's not entirely innate ability, any degree of contemplative thoughtfulness on the part of a developer will make that developer much better over time. The smartest guy in the world can still be intellectually lazy (but I don't see how you *could* be smart without intellectual inquisitively). Thoughtful people gain more valuable experience. People who aren't thoughtful may only be practicing their typing skills.
- Joannes added this as a prerequisite for being a great developer: "… a passionate curiosity for software related matter …." Every very good or great developer I've ever worked with enjoyed software development. I've been interviewing developer candidates lately, and a passion and intellectual curiosity about software development counts far more with me than Trivial Pursuit Q&A exchanges.
- Software development takes a very strong ability for abstract thought. I don't think that concrete thinkers have an easy time with software that's by definition a mental model of something else. I'd say visualization is important, but I've worked with good developers who had zero visualization ability. All the great developers I've worked with did though. People do think differently and have different modes of learning.
You can get Better
Like everyone else I believe that your best bet is to hire the best and brightest, but in reality you have who you have. Maybe the hiring process gets you the wide swings in productivity, but wringing out a 10-30% productivity gain out of journeyman developers is still a substantial gain. Training, coaching, discipline, better practices, communication techniques -- they can all contribute to productivity. "It's not the methodology, it's the man" is a hackneyed and cheap way to get some sort of imaginary high ground in any discussion, but it's partially BS. Anybody can get better, even if it's only in the way they interract with other people in the team. Besides, it's extremely unlikely that you can instantly go and replace poorly performing team members with better developers at will. You're largely stuck with the folks that you have. Making them better is probably your only option.
Following a tangent, when any debate about software practices or processes is going on some clown always pulls out this phrase: "you should just pick the best practices from waterfall, XP, Agile, RUP, whatever..." Hah! I've now seized the high ground you might think. No you haven't, you've simply indulged in the intellectual equivalent of empty calories. It's a worthless statement. The question "what *is* the best way to work" is still on the table. If we knew what the best of everything was, without a shred of doubt, we wouldn't be having the debate, now would we? Plus it's even harder than that because mix and match practices might not work well because many practices reinforce each other. I think you could happily add TDD and CI to any methodology and get some benefits, but they shine a bit more in an adaptive process. On the other hand, doing continuous design or adaptive project management on a codebase without automated tests and CI sounds dangerous to me.
- Posted by justin on January 19, 2007
from: http://blogs.iis.net/thomad/archive/2007/01/17/how-to-speed-up-your-most-popular-web-page.aspx
How to speed up your most popular web page
What's your most popular web page?
I assume it is the default document of your web site, for example if a client requests www.mysite.com IIS would execute www.mysite.com/default.htm. Your default document list is easy to query:
C:\>%systemdrive%\inetpub\adminscripts\adsutil get w3svc\defaultdoc
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.
defaultdoc : (STRING) "Default.asp,index.htm,index.html,iisstart.htm,default.aspx,Default.htm"
What happens for a request to
www.mysite.com is actually pretty simple:
IIS will read the default document list and check file for file if the document exists in the physical directory of your site or vdir. IIS executes the document as soon as it finds the first match. You can imagine that this is pretty expensive. In the above case, supposing default.htm is the only default document that exists in your sites root directory, IIS would check five times until it finds default.htm. And this happens for every request!
The fixes for this problem are obvious:
1) trim down your default document list
2) put default documents that exist at the beginning of the list
Fix 2 has another huge benefit. IIS can put the first default document into the HTTP.SYS kernel-mode cache. It can stay there until IIS invalidates the cache, for example if the default document configuration changes. Kernel-mode caching is now possible because if an existing document is at the top of the list the existence of other default documents doesn't have to be checked anymore.
- Posted by justin on January 19, 2007
Good post on how to get users to read the manual. The post is a little but it has some good points.
How to get users to RTFM
- Posted by justin on January 19, 2007
If you are going on a long trip this is kind of a cool way to plan it.
from: http://blogs.msdn.com/chris_pratley/archive/2006/08/26/725184.aspx
Hey folks, this is a quick note to let you know first of all that I am back on the blog after a 2 month hiatus for baby leave. I've just spent the last hour clearing out hundreds of fairly nasty comment spam so sorry if you had to endure that in your visits while I was gone.
Skye is growing up already (13lbs after 10 weeks!) and I have to say he's got quite a pair of lungs after a slow start in that dep't. He sleeps incrementally more each night but 3hrs is still lucky. Gee was Ciarán this hard on the sleep cycle?
I actually got to use OneNote quite a bit during my leave for one of my favorite activities to use it for, which is trip planning. We decided that if we were going to have sleepless nights anyway, we might as well have them visiting friends on the East Coast and slumming in Europe rather than Seattle (no movie jokes please). This is the fourth or fifth trip I have planned using OneNote and it really works well. Here's how I do it:
- Decide more or less where you want to go (e.g. Europe)
- Get a map of Europe and clip it to OneNote
- Highlight (with your mouse or pen) some places you definitely want to go. In our case, it was Paris (friends there plus hey, its Paris) and Schwetzingen, Germany (more friends there). After that, it was sort of wide open.
- I already knew we were going to drive, as with two kids and more gear than we could carry going through crowded train stations with loads of steps was not going to work. So I proceeded to connect the dots on the map with places to go no more than about 3hrs drive apart. For each potential place I created a sub page in OneNote (e.g. Bruges/Brugge). I also used Rick Steve's travel guide to make it easier to pick spots to stop. FWIW I find his books, while kinda middle brow (and let it be known that I am strictly low brow), are really good at exactly what I used them for - sorting through where to go since they get right to it with what's worthwhile and what's not and how long each place deserves relative to the others and don’t gush about how wonderful all possible places are. For example, here's a suggested itinerary for Germany and Austria. And he lives in Seattle (well, nearby).
- Next I did a bunch of web research on these places, and followed side tracks to other places that I found mentioned. When I saw some interesting activity or hotel described I copied that bit onto the subpage for that location.
- Each location subpage had a table at the top with vital info such as the name, address and tel number of the hotel we would stay at, departure date, time we needed to depart by to make the next destination's activities, map to the hotel, confirmation number for reservation, etc. These pages got filled in at different times - some places had loads of info really quickly, others were blank for a long time. Often people would email me with ideas for each location so I'd dump those in there too.
- I created an itinerary page with a big table showing where we would be on each date, tentative activities each day, where we would stay, time we had to leave, flight numbers if applicable, etc. Each location was a hyperlink to the subpage where there was more data about that place. This page was very useful as I could see how the whole trip was shaping up, and could adjust the time in each place if we looked like we'd be rushed, or add days to the overall trip, etc. When my wife wanted to see the plan, it was easy to browse the trip by following the hyperlinks to the detail pages.
- Any travel info off the web such as flight data and rental car info I clipped and placed on that itinerary page too so it was all in one place.
- Here's what it looked like (this is a preliminary version). Notice the page titles on the right with each location having its own page.
- Posted by justin on January 19, 2007
Recently Microsoft has released Remote Desktop Client 6.0. They have a version for windows xp (http://www.microsoft.com/downloads/details.aspx?familyid=26F11F0C-0D18-4306-ABCF-D4F18C8F5DF9&displaylang=en) and Windows 2003 (http://www.microsoft.com/downloads/details.aspx?familyid=CC148041-577F-4201-B62C-D71ADC98ADB1&displaylang=en).
Below are some of the enhancements that I found to be useful.
1. Monitor spanning
Remote Desktop Connection now supports high-resolution displays that can be spanned across multiple monitors. The total resolution on all monitors must be under 4096 x 2048 pixels. The monitors must have the same resolution and be aligned side-by-side. Memory is also used on the Terminal server as you build up the screen resolution
To have the desktop of the remote computer span multiple monitors, type Mstsc /span at a command prompt.
2. Visual improvements
Remote Desktop Connection now supports 32-bit color and font smoothing.
To enable 32-bit color, follow these steps:
1. Start Remote Desktop Connection.
2. Click Options, click the Display tab, and then click Highest Quality (32 bit) in the Colors list.
To enable font smoothing, follow these steps:
1. Start Remote Desktop Connection.
2. Click Options, click the Experience tab, and then click to select the Font smoothing check box.
3. Resource redirection
The Remote Desktop Connection 6.0 client also allows you to redirect Plug and Play devices that support redirection.
To redirect a Plug and Play device, follow these steps:
1. Start Remote Desktop Connection.
2. Click Options, click the Local Resources tab, click More, and then click to select the Supported Plug and Play devices check box.