Monday, December 21, 2009

From the Intrawebs - December 21

I've decided to move the posting of my From the Intrawebs series from Friday to Monday. A bit of a theme showed up this week around presenting

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

  • Achieving Flow in a Lean Startup: I believe customer development and the lean startup philosophy have value in any organization. This is a great overview of the philosophy and how to implement it for somebody who belongs in both the development world and the customer world. This defines most startup founders and product managers both.

  • Stunningly Awful Demo Evolution - Have You Ever Seen Demos Get Shorter?: Is every moment in your demo reflecting a solution to a known customer need? If not, it is time to cut the cruft and rethink that demo!

  • The 10/20/30 Rule of PowerPoint: Product management is a presentation-heavy profession. The 10/20/30 rule is appropriate here as well as pitching venture capitalists.

  • The Myth of the Page Fold: Evidence From User Testing: I see this as an example of why bringing in usability experts (either on-staff or consultants) is important to building software. It is so easy to believe in usability mythos that are completely inaccurate and scientifically proven as such.

  • A not-so-brief chat with Randall Stephenson of AT&T: Perhaps the best Fake Steve Jobs article I've read. A compelling read on the problems with short-term thinking that had so become so deeply ingrained in the US corporate culture. WARNING: Vulgar language lies herein.

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are their, not mine. I may or may not agree, but to be on this list I think their opinion is interesting.

Monday, December 14, 2009

Career Change: Product Management Resources

This is part four in my series on becoming a product manager. It is a list of resources that you, as an aspiring product manager, can reference. Part one discusses the career path to a product manager; part two discusses thinking like a product manager, and part three discusses how to get that all-important experience to become a product manager.

There is a pretty broad sampling of books, web sites, communities, and other resources. Product management is a cross-functional discipline, so many of the resources reflect that cross-functional nature. Product management is also a social discipline. If that doesn't come naturally to you, I doubly encourage you to get involved!


Blogs and Websites

This is not actually a list of blogs; it is a list of lists of blogs. There are some very high caliber product management blogs that provide a lot of real-world information on how to manage products.

Other websites that don't fall into other categories also show up in here.


There is a lot of good conversation on Twitter. Worth finding people to follow there.


Training and Education



What resources did I miss? Add your favorite Product Management resources in the comment. You can even include an ad for your service as long as it is truely valuable for the aspiring product manager!

Disclaimer: I have received no payment for any links on this list. Most of the items on the list I have direct experience with, a few I know only by reputation. Make sure to do your own research before you spend money. YMMV. Blah blah blah.

Photo courtesy of Lin Pernille.

Friday, December 11, 2009

From the Intrawebs - December 11

No surprisingly, with the holiday season on top of us, spare time is at a premium. This week's list is small but great!

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are their, not mine. I may or may not agree, but to be on this list I think their opinion is interesting.

User Experience and the Product Manager

When I started my software development career, interfaces were designed by the programmers. Over time, we added a graphics designer to make the buttons a little prettier, then an interaction designer to make sure screens flowed well, and now we have user experience (UX) designers, who design the entire experience a user has with the company.

As the person responsible for the product, you are ultimately responsible for is usability as well. This means you need to think about user experience and usability. But how much user experience (UX) and usability knowledge does a product manager need to lead a successful product?

The answer, like so many in product management, is some (where some is dependent on your situation). There are some situations where the product manager is responsible for the entire UX, but we will ignore those cases as degenerate and instead focus on the more idyllic situation where you have at an interaction designer.

You need some UX knowledge because somebody needs to be able to make decisions about trade-offs, and that you are the best informed to make those decisions. How many times have you sat down with engineers and discussed technical trade-offs? Even if you don't understand the deep inner-workings of the product, you know enough to discuss what different options mean and make an informed decision that is best for your customers, right?

You need to understand enough about UX to be able to have the same discussions and make the same informed decisions with your UX team. Without that understanding, your UX designer will be forced to make those decisions based on her understanding of the product.

To get you started, here are some resources. These resources are meant to provide you with the fundamentals, not to turn you into a UX designer.

Armed with this knowledge, you will be in a much better position to understand what is and is not working in your product's user experience.

What are your favorites for user interaction design? Leave a link the comments below!

Friday, December 4, 2009

From the Intrawebs - December 4

It has been a busy couple of weeks for the Software Maven, necessitating a brief reprieve from regular posts, and even regular reading. Things should be back on track now and regular posts will resume.

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are their, not mine. I may or may not agree, but to be on this list I think their opinion is interesting.

Tuesday, November 24, 2009

Happy Thanksgiving!

For those of you in the United States, I want to wish you all a Happy Thanksgiving this week!

For everybody, this time of the year also marks the beginning of the holiday season, so to all, I will wish a Merry Christmas, Happy Hanukkah, Wonderful Kwanza, Beautiful Boxing Day, Grumpy Humbug Day, and/or Pretentious Wear a Plunger on Your Head Day.

Regardless of what holidays you celebrate, I hope they are everything you hope they will be!

(Ignore this, it'll go away: 7T26M7B7AQP2 )

Monday, November 23, 2009

Career Change: Gaining Product Management Experience

This is part three of a series on making a career change into product management. In part one, I discussed the some of the career paths that lead to product management. In part two, I discussed the change in focus that is a requisite part of becoming a good product manager. Now let's talk about gaining experience!

Get a Mentor!

Much like driving, product management is most often learned by doing. There are a ton of resources available to increase your knowledge (We'll discuss many of them in part 4 of this series!), however, the more experience you can get on the job, the easier your transition will be.

Fortunately, most product managers are overworked and are more than willing to get some help. In addition, as I was making the transition from software engineering to product management, I never found a product manager who wasn't willing to mentor. He gets help; you learn. A win-win.

Your ideal mentor needs to be a good product manager. If you are frustrated with him in your position, he may not be a good person to be mentoring you. That is especially true if many people on the product team are frustrated by him! It will work best if he manages the product you are working on, but that is not necessary.

Structure Your Learning

To the right is the Pragmatic Marketing Framework™ (click to open a larger version in a new window). Pragmatic Marketing is one of the preeminent sources of product management training and knowledge. The Framework gives a guide to what a product manager's job is. I strongly encourage you to enroll in their seminars if you have the opportunity. You will learn a lot!

Even if you don't enroll in their seminar, you can use the Framework as a guide for experiences you should gain. If you've been involved in any portion of product development (anywhere from requirements to sales and support), you likely have experience that overlaps with the Framework. This is good, and we'll discuss how to present that experience in part 5 of the series.

From Here to Product Manager, With a Map! (An Example)

Let's look at an example of how you can use the Framework to guide you. In this case, we'll be a hypothetical engineer wanting to move into product management.

Engineers are very familiar with the whole product development cycle, as they are usually involved in some way from soup ("How long would this take?") to nuts ("Our biggest client's migration went bad, we need you to fix it!"). The earlier and later you can be involved in that process, the better.

The down-side is that engineers are often kept behind closed doors. This is done primarily to protect engineers from distractions and, occasionally, to protect customers from some engineers. Customer face-time is a major hurdle engineers need to cross.

For our hypothetical engineer, the priorities and associated Framework tasks to get involved with are be:

  1. Interacting with customers. Looking at the Framework, Win/Loss Analysis is a great place to start. I would follow that with as much of the Support column as possible.

  2. Understanding the market. If you've been working on Win/Loss Analysis, you have some great insight that can be added to the Buy Personas. You also could have some valuable insight into Positioning. You may not get the whole box for these tasks, but you can provide valuable input to them.

  3. Figuring out the business. Now you are providing help on items like Distribution Strategy, Pricing, and the Business Plan.

Getting "Career Progression" Support

Often, you will need to spend your own time working on this. This is no different than a software engineer reading technical books on her own time. Ultimately, to succeed, you have to expand beyond your nine-to-five responsibilities.

You also need to have the approval and support of your boss. Even if you are working on these things after hours, these activities will take time from the normal office routine. You can't get input from a customer on a win/loss analysis at 11:30 at night.

Again, fortunately, most employers see this type of activity as a win-win. Career progression is critical to employee satisfaction, and your boss won't have to do anything to give you progression. If you are providing more time on the job, then you are also giving extra value to the company.

If your current employer isn't willing to be supportive, then I strongly encourage moving on to a supportive environment before moving forward. If you don't, you will experience a lot of frustration trying to work around that.

Wrap Up

Get a mentor, identify your weaknesses, identify a path to strengthen those weaknesses, get your boss' support, and get to work. Keep track of specific achievements: "Instrumental in closing 10 sales worth $25M" and "Performed 75 win/loss analyses that drastically altered the selling processes and increased win-rate by 8%" type statements are gold on your resume.

Tricks to Get in Front of Customers

As I mentioned before, customer face time for non-customer facing individuals can be very challenging. It is also absolutely critical. As such, I'll end with a few tricks I used to make that happen. These tricks require your boss' support, so make sure you've got it!

  • Meet sales people. Sales people love to bring other product people into sales calls. Your mentor should be able to introduce you. If the sale call is a live visit, Sales will often have budget to pay for your trip. This keeps your boss happy!

  • Present at user group meetings and other conferences. As a product manager, you will need to be able to comfortably present to a group of people. Depending on the specifics, there may be separate budget for this, so, again, your boss is happy.

  • Attend focus groups. If your company does live focus group meetings, ask to be present. Depending on your current role, you can sell this as an opportunity to learn more about your customers so you can do your job better.

  • Manage the beta program. If you can volunteer to run the beta program, you have a great opportunity to interact with customers and learn how they use the product. Additionally, it may save somebody else who is very uninterested in doing that.

Friday, November 20, 2009

From the Intrawebs - November 20

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

Disclaimer: Unless otherwise noted, I have no affiliation with linked properties other than being an interested reader, a happy user, or a potential customer: Nobody pays to receive a link. Any opinions of linked properties are their, not mine. I may or may not agree, but to be on this list I think their opinion is interesting.

Tuesday, November 17, 2009

Engineer Respect

Is this what the engineers you work with think about marketing?

If it is, it is almost guaranteed they feel similarly about product management.

I've experienced this attitude from three different perspectives: as an engineer giving it, as a functional manager trying to get engineers over it, and as a product manager receiving it. Few things will derail product development as badly as this attitude. Complete with this attitude comes the corollaries, "I know the product better than you" and "your opinion doesn't really matter."

If you want to succeed with your product, you must address this, and addressing it takes leadership, not confrontation. No matter how important you say you are, engineers aren't going to change their beliefs until they see how important you are.

Here are some steps you can take to address this attitude. It is not always fast. However, unless you are stuck with the perpetually egotistical engineer (and at most 1 in a 100 are that way), you can prevail!

Your opinion doesn't matter

Acknowledge to yourself that they are right, your opinion doesn't really matter. Engineers are analytical. You need to have real data to be taken seriously. If you don't have real data, get to work.

Know your product

Know your product. Nothing will kill credibility like not knowing your product inside and out. Seems obvious, but I've worked with product managers who didn't and I've seen the problems it caused as they tried to work with engineering.

Each product gaffe that you make (like calling to ask how to use that widget that's been in the product for years) does serious damage.

Avoid business jargon like the plague

The video mocks the term "marketecture" and other business jargon for a reason. If you do have to slip into jargon, make sure it is understood. Never, ever use the word, "synergy".

If you are trying to achieve a result that is greater than the sum of the inputs (e.g. "synergy"), explain it in detail. What is the effect you are looking to achieve and why do you think what you are attempting with achieve it.

Keep the engineers informed on what you are doing and why

Visiting a customer? Let them know what you are trying to accomplish. Asking for A/B testing functionality? Let them know what macro indicators you are trying to learn.

This helps engineers know that you aren't just jaunting around for fun and has the side benefit that you might get very useful feedback that can make your job easier. That is a real win-win.

Get engineers into the wild

The more isolated your development process and organization keeps engineers, the more entrenched the anti-marketing sentiment can become. It can become bad enough that the engineers truly believe that the business exists solely because of them.

Combat this by getting engineers in front of customers with you. This builds empathy for the customer, and, indirectly, for you as the voice of the customer.

Solicit feedback from engineering

Any time you can, solicit feedback from engineering and incorporate that feedback into your product. Engineers do know the product best and may have insights that neither you nor your customers have had. More importantly, this builds trust (really listening to somebody always does), which helps cement the results of the other steps.

Paul Graham contends that it is easier to teach an engineer the business ropes than to teach a business guy to be an engineer. While probably true in general (there are some specific examples of engineers I'd never put in front of a customer), it also propagates the ego-driven belief that engineers have the only hard job in the company and, consequently, the only important job.

You need to help them understand that in most software companies, the primary risk to success for most companies is not technological risk but, instead, is market risk. It is unlikely you will hit a technology hurdle that cannot be cleared, so the product dies (unlike, say, pharmaceuticals, where a drug that doesn't work won't sell). More likely is that you will create a product that nobody cares about, so the product will die, regardless of how awesome the code is. That is the value you are providing.

It doesn't take much to successfully change attitudes: just time and consistency. Good luck!

Friday, November 13, 2009

From the Intrawebs - November 13

This week's picks are up. Thanks to everybody out there who spends so much time writing for my edification!

If you find something that you think belongs on this list, send it to me via @SoftwareMaven on Twitter.

Monday, November 9, 2009

Career Change: Thinking like a Product Manager - It's the Why

This is part two in a series on becoming a product manager. You can find the first article here.

For any number of reasons, you are eyeing product management as a future career. Whether its the innumerable business trips or the responsibility without authority, you know its the path you want to follow.

Congratulations! You are in for a wild ride.

There is a lot you are going to need to learn, much of which will be on the job. Things like how to placate a surly engineer, how to make a customer feel good about your product, how to guide executives to your way of thinking will become second nature to you and the more you have done previously, the easier it will be to assume this new role.

Even before you begin learning those things, though, you have one of the most difficult tasks in your career in front of you. This task is difficult for all fields entering product management, but I think it is particularly difficult for software engineers.

Stop Thinking About Who, What, When, and How.

In the intro to the series, I discussed career paths into product management and their focus (who, what, when, and how). Figure out which you are and consider, as a product manager, the following applies:

Who: You need to relinquish your control over deciding who the right person is to complete a task. This can be disconcerting when you know who the right choice is. Furthermore, it can cause serious friction with other managers.

What: You need to understand the reasoning for the what to build. It can be very easy to fall back into a comfortable place of writing requirements.

When: You need to step back from the highly tactical world of what comes next. Certainly, successful execution is important, but if you are running your product through a Gantt chart, you are missing the strategy that will differentiate your product and bring real success.

How: You need to recognize that your job just got a lot broader. With that breadth can come a feeling of "not getting things done" or disconnectedness after years of intense focus. If you continue to focus on the how, you will miss business drivers that guide your product and you will risk disenfranchising your engineering team by minimizing their expertise and taking away their responsibilities.

Start Thinking About Why!

This is the switch from tactical to strategic. This is understanding where the market is today and being ready for where it is going tomorrow. This is understanding what causes one customer to purchase and another to pass.

Every time you lay down a feature in an MRD, you will need to have data supporting it. Beyond describing the feature, beyond saying how many people will love the feature, beyond comparing competitor feature sets, he data should describe why the feature is important.

Consider the difference:

The product must support features X and Y because 73% of customers say they want it.


The product must support features X and Y because 73% of customers say they want it, including the majority of buyer persona who perceive them as critical points of comparison. These features will reduce the time it takes to close sales, increase out win rate, and strengthen our reception by analysts.

Figuring out the "why" will be the most challenging thing you'll do as a product manager. It will also give you the respect of your co-workers, the trust of your executive team, and the foundation for success for your product.

Start practicing in your next product meeting. Start asking why, and if the product manager doesn't have the answer, it's a great opportunity for you to offer your services to help find out.

The next article in the series will discuss gaining product management experience.

Special thanks go out to Jeff Lash and his blog, How To Be A Good Product Manager.

Friday, November 6, 2009

From the Intrawebs - November 6

Been a very busy week for me, so I haven't had a chance to get the post out I was hoping to. In the meantime, here is this week's picks.

Friday, October 30, 2009

From the Intrawebs - October 30

Halloween is my favorite holiday of the year. I hope yours is awesome (no way am I going to say "spooktacular"! Oh, wait, doh!). Don't forget to watch out for your future customers: drive slow and stay alert for kids out trick or treating.

Found some good stuff out there this week. Hope you enjoy it! If you are interested in seeing my picks in real-time, you can follow my From The Intrawebs RSS feed.

Wednesday, October 28, 2009

Career Change: How to Become a Product Manager

There are many paths into product management in the software world. Whether it is putting your product knowledge to work as a software engineer or your customer knowledge as a sales engineer, one thing that seems to be consistent is that you need a background in software to manage a software product.

I'm going to spend some time talking about how to make that change into product management. Many of these concepts will apply to anybody wanting to transition into product management, but we may cover some topics that are specific to where you are coming from.

As a starting point, let's identify and characterize some of the "standard" career paths that you can take in product development:

You can go down the technical path, becoming an architect or a principal engineer. I call this the "How" path, because your job revolves around how to accomplish the needs of the business.

Another path is into functional management, progressing from a team lead through manager and into director. I call this the "Who" path, because you primarily are concerned with who will accomplish the needs of the business.

Tangential to functional management is project management, which is the "When" path. Your primary focus is the scheduling of deliverables.

I would categorize the path through business analysis as the "What" path. This may be an intermediary step to get to product management for many people. As a business analyst, you define what needs to be built and delivered.

The last common option, and the one we are going to concern ourselves with, is product management. This is what I call the "Why" path.

Any time you change your career path, you will be required to change the way you approach solving problems.

I can see many people arching their eyebrows and muttering, "The product manager is the one who says 'What'." My argument is that the "What" is a by-product of understanding why a market exists and is experiencing a problem that your company is capable of solving.

I have a lot of ideas swirling around on the topic of making the transition to product manager, far too many for a single post, even with my (too?) lengthy prose. As such, I'm going to make it a series of posts.

  • In part two, we will discuss the mental shift required to move into product management. This is one of the most difficult steps and your success with this step will determine whether it is an appropriate career path. We will also discuss what you will give up when you make the switch.

  • Part three will explore how you can gain product management experience while you are still doing your day. There are many things you can start doing today to assist in your career change.

  • Part four will review options for gaining the remaining knowledge and experience you will need to make the transition.

  • Finally, we will wrap it up with a discussion of getting that all-important first job, including how to present yourself during your job search if the first job is not at your current employer.

I am going to bring multiple viewpoints into this discussion, both through conversations with others in the product management community, through the existing body of work already out there, and, hopefully, through your feedback.

Special thanks go out to Bob Corrigan for his early feedback on this topic. His ack/nak blog is a great source of Product Management information. You should read it!

Friday, October 23, 2009

From the Intrawebs - October 22

Here is this week's reading list...

Thursday, October 22, 2009

Everybody Is My Customer!

You are going to build an amazing product. It is going to revolutionize the way a market works. It is awesome to the extreme (Dude!). Because your product is so amazing, you know the entire market is your customer base. You certainly don't want to limit your sales potential by limiting your customer base to a segment of that market, right?


In the consumer and small biz software world, we generally shoot for a hockey-stick growth curve. Enterprise software is a little more difficult to have that kind of a growth curve because it is high touch, but we still would like to see the curve moving upwards. In both cases, though, each progressive sale becomes easier than the sale before it.

That is an important concept, so I will repeat it. Selling your product to the 1,000,000th customer will be easier than selling it to the 999,999th customer. In an exponential growth curve (e.g. the hockey stick), it is exponentially easier to make the next sell.

Being Infinitely Hard

OK, the first sell is not infinitely hard, but it is amazingly difficult (we'll ignore the copy Mom bought because she believes in your company...). The first buyer is buying completely on faith: faith that you will survive as a company and succeed as a product, faith that you will deliver the future you promise, faith that you will really solve her problems. Even if your product is free, a leap of faith is required just for the time investment required.

This is what you need to be thinking about as you plan your initial release. It is not the easy 1,000,000th easy sale, but the very hard first sale that matters.

Make It Easier

With that in mind, how can you make it easier? The closer your software and marketing matches the needs of a highly focused group in your overall target market, the easier that first sell will be. Now is the time to put your product management hat on, identify that focused group, and start building value specifically for them. As development continues, product marketing (yeah, it may be you again...) will start to craft a message tailored specifically to them. Your launch will be tailored around this tightly focused group, getting them on board, and making them extremely happy.

There is a fringe benefit to having a tightly focused group of customers: they form the foundation of your tribes, who are absolutely critical to your success.

With your tribe of happy customers, you are ready to conquer the world and start taking advantage of ever-easier sales. Remember, even Facebook started with just Harvard and dreams of owning the whole college alumni population. Imagine if Facebook had said, "We have a product perfect for every college student, we don't need to start with just Harvard." Do you really think they would be where they are today? Is your product poised for more success than Facebook was?

Friday, October 16, 2009

From the Intrawebs - October 16

This is the first installment of a weekly series called "From the Intrawebs." I will identify the best of what I read, watched, or heard through the week. This week's list is a little short, but better to start small than not start at all.

That's it for this week. If you have something that you think belongs on my must-read list, drop me a line in the comments or via e-mail.

Thursday, October 15, 2009

The Perfect Product to Manage

It's the ideal product to manage, right? A product that you, the product manager, are the ideal customer. Immediately, your workload is cut in half because you can validate your own requirements, your own messaging, and your own positioning. It's a product for you, after all.

Of course, this couldn't be further from the truth. The reality is that if you are managing a product for which you are the ideal customer, you need to be extra careful to ensure your own personal biases and assumptions are not polluting your product.

When you start hearing yourself thinking, "Yes, this would make my work so much easier," or, "No, I would never use that kind of feature," you need to get out and start talking to your market to validate that it would make their work easier and that they would never use that feature.

Otherwise, you may wind up building a product for which you are the only customer.

Tuesday, October 13, 2009

How Soon Do You Need a Product Manager? (Part 2)

I've kind of had a theme going on here over the last few posts. I started with How Soon Do You Need a Product Manager. Then I told the story of a company that failed to capitalize on its awesome technology because of a lack of market focus in The Influence of Tribes on Product Success. Finally, I pointed to some others who share my views on the importance of product management in early-stage companies in "Hire Product Management First". Now it's time to wrap this theme up (for the time being, anyway) by responding to my closing comment in How Soon Do You Need a Product Manager: "But, but, but, we are a start up. We can't possibly understand customers, market, and products until we release something. Then the market will tell us where we are wrong."

This way of thinking has been codified in many software entrepreneurs' minds by writings by Paul Graham, Eric Raymond, and, really, by the entire Agile movement, all of which is very good advice. Unfortunately, it is taken as a replacement for customer development instead of an important piece of it.

Starting Up Without a Product Manager

Founders are good at identifying gaps in existing markets and building new companies to fill those gaps. Customer development in a start-up is often nothing more than some vague impressions about the under-served markets defined by those gaps.

Now the company turns inwards for the next six to nine months, maybe a little less for those that really get release early, maybe a little more for those that don't. The features in the first release are all determined by anecdote, by socializing, or by fiat. Everybody in the company is convinced of how great the product is because they keep telling themselves that and there is nobody to disagree.

Now we are coming to release and the company starts looking outward, really for the first time. The company doesn't really know who its customers are, so, in order to find any customers, it needs to shout into the crowds. The goal being to get some subset of the under-served market the founder identified to self-select and become a customer. Depending on the size of the market and how well defined it is, that can be a lot of shouting.

Maybe some customers trickle in, maybe they don't. If they do, revision two of the software is all about pleasing them, and the company needs to move quickly. If they don't trickle in, then revision two is all about throwing another dart at the dartboard to see if it gets closer to the market's needs. The scary thing about this is that the product may be perfect; other factors, such as positioning, messaging, or any of a host of other non-technical reasons, may be keeping people from buying.

Starting Up With a Product Manager

The whole goal of starting up with a product manager is to ensure that, at release time, there are some customers excited for the product. She will do this through a series of activities, all of which are outwardly focused, but will be affecting activities internally.

  • Identify and define the subset of the market that will buy.

  • Identify their greatest pain points and ensure development solves those.

  • Identify who is competition, who is a potential partner, and who is irrelevant.

  • Understand what the minimum feature set is that will enable a customer to jump to your product.

  • Analyze what communications channels will get the potential customers' attention.

  • Determine a message that will resonate with potential customers.

  • Enlist the first customers to provide feedback prior to release.

  • Price the product.

The product manager will look at the under-served market the founders identified and determine specifically how it is under-served. Who is the competition and how are they not servicing those needs? How can your product be positioned relative to the competition?

The product manager will start with the under-served market the founder identified and segment that until she finds a small group of potential customers that can be communicated with directly.

Isn't the Founder the Product Manager?

Actually, the ideal is for a founder to be the product manager. The company would be in a great position if a founder, passionate and visionary, was also the one who was ensuring the company had customers ready for the product it was building. If that's your situation, run with it. You are in a good position.

Many times (most?), however, founders are technology, finance, or sales people. These are great people to have involved in a start-up, but rarely do they have the experience and knowledge of how to drill down from a market to customers and then build back up from a concept to a product that those customers will buy (as opposed to a product that they think is killer).

Release early, release often. It is one of the great strengths of a start-up. Don't waste that strength by needlessly spinning wheels trying to figure out what a customer might want. A good product manager, properly empowered, will give you strong hypotheses. At that point, releasing early and often is about optimization, not about feeling around blindly for the market.

Isn't it worth one person in your company to keep all of the developers, QA, marketing, and sales focused in the right direction?

Friday, October 9, 2009

"Hire Product Management First"

In How Soon Do You Need a Product Manager, I argued that product management should be hired very early in a company's life. In The Influence of Tribes on Product Success, I told of what happened to one start-up that did not successfully managed the gap between technology and customers.

It turns out, I'm not the only one who feels this way. Check out this post by Saeed at On Product Management blog. In short, Bill Campbell, CEO of Intuit agrees.

If you have a start-up, don't under-estimate the value of a product manager. It is about far more than just prioritizing features!

Sunday, October 4, 2009

The Influence of Tribes on Product Success

I've been reading Seth Godin's Tribes. It's a short, quick read like most of Seth's books. I've also been reading Steve Blank's series on the customer development model. The combination has me thinking about successes and failures I've seen. Two in particular come to mind as particularly illustrative.

What's come to my mind as I've thought about these is the coolest product in the world is worthless if you can't connect with a buyer, and, conversely, the minimum required product may be much smaller than you think it is and the level of finish required may be rougher than you expect. Many companies spend countless hours on building the most amazing widget with the assumption that the customers will flock to them, only to be disappointed. Other companies put out something barely distinguishable from cruft, yet they maintain a loyal following. The difference is in the approach to developing customers, or in building a tribe.

Story Time 1: Starting with Customers

We were selling a web content management system for colleges. We initially tried to OEM a product from a partner, but that product failed to meet the needs of our market in so many ways, so we decided to build.

For a variety of reasons, we were actually able to freeze most of the market for nearly two years while development went to work. During that time, we were working very closely with a small set of customers who understood the problem and wanted to be at the bleeding edge of solving it.

As we started to get closer to the release, we brought in new customers to this group. Our initial customers had told us what would resonate with the type of customer we wanted to sell to. With this set of customers, we were able to test that resonance. I was surprised at how strongly this group of customers supported us. We had a small group of customers that were talking positively to other potential customers about our product, and they hadn't even seen it yet.

A Doomed Product?

Release came and, to be completely honest, the quality was...hmm...abysmal seems fitting. We pushed something out the door that we knew wasn't ready, but we were a year late and the market that we had successfully frozen was thawing rapidly.

A poor product, a year late, sales and services not ready for the release, a product manager leaving the company, competition increasing and maturing. Certainly the product was doomed, right?

Our Customers Make Us Succeed

Amazingly, no, it wasn't. It was not an easy year after that release, but we had invested enough in our customers that they wanted to make sure we succeeded. They gave us every opportunity to make things right, continuing to be positive voices for our product even when going through pains caused by us.

Yes, it was in their own interest for us to succeed at some level, but none of these early customers had invested so much in the product that they couldn't have pulled back. Instead, because we focused on really understanding the target market, engaged very deeply with that market, and committed personally to them, we built real relationships. We were leading a tribe and the tribe wanted us to succeed.

Story Time 2: Platform as a Service

I don't have the complete history on this one, as I wasn't there the entire time. I will paint as complete a picture as I can, however. I was not involved with managing this product; I watched this from the proverbial side-lines.

This product was one of the coolest products I've worked with. Even now, I think about what these guys are doing, and I'm impressed. Leveraging the move to the "Cloud", this company is building a web-based development environment. Imagine an environment where you can build incredibly interactive web applications (including drag and drop, dynamic lists, and all sorts of other AJAXian goodness) all within your browser. Now, take it one step further, and imagine that the cool app you just built could be versioned and deployed to the web by clicking the Deploy button. Very impressive stuff, and it really worked!

Build It and They Will Come...Right?

"Yelling at the crowds" is what Seth calls it. We were really good at doing it. The press knew who we were, and they liked us. We talked to a lot of people at trade shows. We gave away a lot of shirts. We even had a podcast. Oh, and we had a freaking amazing product. Surely people would be beating down our door, right?

Lots of people would come check out the product. They'd sign up for an account, tinker for a couple of hours, and disappear. Not very encouraging.

Managers Will Get It!

Well, developers are a religious lot with deep convictions in their development tools, so we'll go to their managers. How could their managers not love the value proposition we are selling? Hire a business dev guy (not calling it sales because we're not an enterprise software company and we will not have a sales staff) to help guide companies in and hire a program manager (oh, hi, that's me) to guide them through and back out again.

We have some luck talking to big names and some luck developing some software for no-names. We have no luck getting big names to try developing (much less buying anything). The no-names are companies so small or project so insignificant that nobody cares. Those companies are there because they are getting custom software for free. Huzzah!

What Happened?

A few months later (a long time at a start-up), and the company suddenly gets a LOT smaller. A month later, and it gets even smaller (oh, bye, that's me). Over the next six months, it continues to get smaller. But this technology is freaking awesome! What happened?

Turns out, we never knew who our customer was. We were so busy building a cool technology that we didn't stop to figure out who was really going to pay for it. Everybody in the company was an engineer, so we didn't need to go outside the company to figure out what to build. We built what we would use (well, not quite, but that's a story for another day). We just kept telling ourselves that every developer is our customer; it's a big pool, so we'll be fine..

For two years, the company was heads down, building an awesome technology, but never stopping to figure out who was going to buy it. They drank their own Kool-aid to the point that they knew people were just going to flock in. All they would need would be a gentle nudge in the right direction. All of their energies were focused inside the company.

Where Did They Go Wrong?

We could talk a lot about the specifics of this case and what went wrong. I think it would make a fascinating case study and maybe one day, I'll sit down with the founder, the CEO, and a few others, and make such a case study. Not today, though.

Instead, we'll paint with a broader brush and identify a few key points:

  1. Focused Inwards on Technology: It is a great technology, but they told themselves that too many times. They turned all their energy inwards to build it without ever vetting that they could sell it or understanding whom they would sell to. A technology is not a business. Even the employee balance in the company reflected this with well over 50% of the company in engineering.

  2. Didn't Build a Tribe: They never built a tribe around their product. This product had some unique constraints that made it very hard to build a tribe around. Even today, I'm not sure who the right customer is. If you can't answer that question, you don't have a product. If you don't have a product, you don't have a business.

  3. Features Weren't Focused: Because there wasn't a targeted customer guiding the development, features weren't prioritized to sell to that customer. Instead, they were prioritized based off of the importance to the technology.

Like I said, I don't know all of the history that lead to this outcome, but I did see the outcome, as of the end of last year. I hope they've addressed these issues, because if they haven't, I would question their ability to succeed.

Wrapping It Up

My experiences are anecdotal, I fully admit. However, they are illustrative of larger patterns that have been documented many times by many people. These are the stories that caused people like Steve Blank and Seth Godin to write what they did.

It is easy to get wrapped up in the product for the product's sake. Doing so is a recipe for disaster. Whether you call it customer development or building a tribe, the end result is that you need to understand who is laying out the cash and why they are willing to do that. Once you do that, you will understand what you need to do to lead them, whether there are five or 500 customers in your tribe.

Wednesday, September 30, 2009

Redefining Myself

Careers are funny things. You start out thinking you know where you want to go and what you want to do. I started out knowing I wanted to write code. I knew that by the time I finished ninth grade. Everything after that was in pursuit of that goal. I graduated with a computer science degree and quickly went to work: a game studio, a couple of 3D software companies, then onto the Interwebs in a dot com.

Then a funny thing happened. I found out that there were other problems than those solved by algorithms. These problems involved people, and, wow, they were much more difficult to solve. In fact, many times, there was no solution; the best I could hope for was a good compromise. What a change from the deterministic world of writing software!

I took advantage of some opportunities that were presented to me. I spent some time in functional management, I spent some time in program management, and I spent some time in product management. I grew a lot, and I found out a few things about myself:

  1. I am more happy focusing my energy outwards than inwards. I like working with customers.

  2. I am better with customers than I ever thought I would be. I'm not a natural extrovert, so this was a surprise to me.

  3. Understanding customer problems and turning that into working software that solved those needs was very fulfilling. Doing so profitably was awesome.

  4. Successfully working with people requires figuring out what makes them tick. That small amount of "psychology" has caused me more personal growth than any other aspect of my career, and I am a better person as a result.

As a result of those opportunities, I found that I really enjoy product management. I like herding cats to get a release out the door. I like getting inside a customer's head. I like working with engineers until they share that knowledge. I like jumping in at the end of a long sales cycle and giving that last little nudge that pushes a sale over.

Unfortunately, in too many ways, my resume still says "engineer" and not "product manager." In an up-economy, that would be challenging; in a down-economy, it is down-right painful. I am greatful to have a marketable skill, but I would rather be doing what I really enjoy.

I've struggled for a while with this, trying to figure out what the best path forward is. One path says, "Go get an MBA", another says, "Tough it out, things will change later", and another, more insidious one, says "You are stuck where you are, so just deal with it."

An MBA...there are so few MBA programs that specialize in product management. I've talked with many product managers about the value of an MBA, and, without hitting a specialized program, it doesn't seem to be valuable to the tune of $20,000 or more. From the people I've talked to, maybe 20% of the classes would be truly useful, and of that 20%, I already have a strong enough working knowledge to succeed. Hard to stomach $20,000 out of my pocket to get a single-digit improvement. Who knows, maybe I'll be revisiting this decision in a couple of years.

Toughing it out is sort of a default. I have to have a job. I will take employment wherever I can. That option isn't really doing anything; it's just staying alive. However, as time goes on, it will become harder and harder to change, so the option of doing nothing is, in all reality, regressive.

What I can't do is "just deal with it." My personality doesn't work that way. The only thing more frustrating than not being where I want to be, is not even moving in the direction I want to move at all. And frustrating it has been.

This week, I made a decision and struck off. This is a journey to redefine myself, and the goal is to come out the other side in the place I want to be, regardless of economies or degrees. Here are the steps I'm taking:

  1. Joining the Product Development and Management Association. This gives me access to research on product development, access to networking opportunities, and provides some indication that I'm serious about this transition.

  2. Increasing my reading on product development and management related topics. This will cover anything from Making Things Happen to Tribes, to The Journal of Product Innovation Management.

  3. Writing about product management. This is an important part of the redefinition, because it is the first place it becomes publicly visible. I'm going to write here on my blog, on Twitter, and on other sites.

  4. Joining and becoming involved in product management communities. Certainly the local product management associate (The Utah Product Magement Association), but also some on-line communities that I have yet to define.

  5. Certifying professionally as a product manager through the PDMA.

  6. Applying these things to a personal software project I am working on.

In the end, not only will I be a better product manager, but others will be able to see the capability and knowledge that I have. Wish me luck!

Saturday, August 15, 2009

How Soon Do You Need a Product Manager?

I recently had lunch with a colleague who is leading a very early stage start up. His company is building a product targeting product managers, so our lunch was a fact finding mission for him. During the course of the lunch, he asked me how big does a company need to be before it needs a product manager.

This, in my opinion, is a fascinating question that is worth taking some time to answer. Companies succeed or fail based on how they answer this question; even a company with three people like my friend's. In fact, I think small companies are more at risk when they answer this question wrong. As such, let's focus on the small start up.

Early in a company's and product's life, development velocity is very high. It is both fast and easy to add new features. This velocity is one of a start up's greatest advantages in the marketplace. Over time, this velocity slows as development complexity and support burdens increase, reducing the start up's advantage. It is, therefore, critical to make the most of that early velocity.

Development at a start up is usually guided by two things: the founder's vision and feature creep. The founder has a notion of what the product will be and who the market is. Development usually proceeds based on those notions, using the velocity advantage to throw as many features as possible into the product. It often feels like we are throwing spaghetti at the wall, hoping more sticks than falls.

The danger with this approach is that every piece of spaghetti that falls on the floor has a cost, not just the cost of developing that feature, but also the opportunity cost of what wasn't developed and the future reduced velocity to develop features the customer will pay for. To maximize success, we need to minimize that loss, and that is what a product manager is there to do.

I can imagine the immediate response to this will be, "Isn't that the founder's job?" In an ideal world, I'd say yes; however, more often than not, they are not able to do it. Let's look at why that is:

  • Founders are busy being pulled in multiple directions by everything inside and outside the company. They rarely have time to do the legwork necessary to understand the specifics of the market. Instead, they paint with broad brushes. depending on velocity to make up for precision.

  • Founders are biased. The passion that draws them to found a company biases them to the idea the way they see it. This is good to get the company moving, but, again, it depends on velocity to succeed, which may not be enough if the original idea isn't close enough to the actual market need.

  • Founders may not have the knowledge to understand the market. Founders are often extremely talented individuals with strong knowledge of their subject area, whether it is technology, sales, marketing or some other aspect of the company. Building a successful product requires understanding the trade-offs and needs of each organization in the company, even if those organizations are just a hat a person puts on for a couple of hours a week. Start ups will frequently overcome this only by scrambling and learning on-the-job.

Coming back to the original question: How soon do you need a product manager? The answer is it is never too early. Small companies so often succeed by depending on their velocity advantage, an advantage that diminishes over time. How much better off would those companies be if they succeeded by understanding their customers and their market, and used that velocity advantage to generate a significant margin between them and their competitors.

"But, but, but, we are a start up. We can't possibly understand customers, market, and products until we release something. Then the market will tell us where we are wrong." I'll talk about that in my next post.

Friday, May 22, 2009

Rounding Corners on a UIView

I've been working on an iPhone application for the last couple of months in my spare time. One need I came across that I couldn't find an existing solution for was being able to round the corners on an existing view. Specifically, I need to include a UITableView as a child view of another view, but UITableView has hard corners, which looks wrong on the iPhone. This class will soften the corners.

The RoundedView should be added last to the container that holds it, so it is drawn on top. Events are passed to the next responder. You can set the radius of the corners and the color of the fill. You can also turn on and off which corners are drawn rounded.

Sample Usage
- (void)viewDidLoad {
    [super viewDidLoad];

    UIView *tableView = [self.view viewWithTag:kTableViewTag];
    RoundedView *rv = [[RoundedView alloc] initWithFrame:tableView.frame];
    rv.cornerColor = [UIColor colorBlue];
    rv.radius = 10;
    rv.roundLowerLeft = rv.roundLowerRight = NO;
    [self.view addSubview:rv];

#import <UIKit/UIKit.h>

@interface RoundedView : UIView {
    int radius;
    UIColor *cornerColor;
    BOOL roundUpperLeft, roundUpperRight, 
         roundLowerLeft, roundLowerRight;

@property (nonatomic,retain) UIColor *cornerColor;
@property (nonatomic) int radius;
@property (nonatomic) BOOL roundUpperLeft;
@property (nonatomic) BOOL roundUpperRight;
@property (nonatomic) BOOL roundLowerLeft;
@property (nonatomic) BOOL roundLowerRight;


#import "RoundedView.h"

// Private methods for RoundedView
@interface RoundedView() 
-(void) drawRoundedCornersInRect:(CGRect) rect inContext:(CGContextRef) c;
-(void) drawCornerInContext:(CGContextRef)c cornerX:(int) x 
        cornerY:(int) y arcEndX:(int) endX arcEndY:(int) endY;

@implementation RoundedView

@synthesize radius, cornerColor, roundLowerLeft, roundLowerRight;
@synthesize roundUpperLeft, roundUpperRight;

-(id) initWithFrame:(CGRect) frame {
    if (self=[super initWithFrame:frame]) {
        self.cornerColor=[UIColor clearColor];
        self.backgroundColor=[UIColor clearColor];
        roundUpperLeft = roundUpperRight = YES;
        roundLowerLeft = roundLowerRight = YES;
    return self;

- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event {
    // We pretend like no points are inside our bounds so the events
    // can continue up the responder chain
    return NO;

-(void) drawRect:(CGRect) rect {
    CGContextRef c = UIGraphicsGetCurrentContext();
    if (c != nil)  {
        CGContextSetFillColorWithColor(c, self.cornerColor.CGColor);
        [self drawRoundedCornersInRect:self.bounds inContext:c];

-(void) drawCornerInContext:(CGContextRef)c cornerX:(int) x cornerY:(int) y
        arcEndX:(int) endX arcEndY:(int) endY {
    CGContextMoveToPoint(c, x, endY);
    CGContextAddArcToPoint(c, x, y, endX, y, radius);
    CGContextAddLineToPoint(c, x, y);
    CGContextAddLineToPoint(c, x, endY);

-(void) drawRoundedCornersInRect:(CGRect) rect inContext:(CGContextRef) c  {
 int x_left = rect.origin.x;
 int x_left_center = rect.origin.x + radius;
 int x_right_center = rect.origin.x + rect.size.width - radius;
 int x_right = rect.origin.x + rect.size.width;
 int y_top = rect.origin.y;
 int y_top_center = rect.origin.y + radius;
 int y_bottom_center = rect.origin.y + rect.size.height - radius;
 int y_bottom = rect.origin.y + rect.size.height;
    if (roundUpperLeft) {
        [self drawCornerInContext:c cornerX: x_left cornerY: y_top
              arcEndX: x_left_center arcEndY: y_top_center];
    if (roundUpperRight) {
        [self drawCornerInContext:c cornerX: x_right cornerY: y_top
              arcEndX: x_right_center arcEndY: y_top_center];
    if (roundLowerRight) {
        [self drawCornerInContext:c cornerX: x_right cornerY: y_bottom
              arcEndX: x_right_center arcEndY: y_bottom_center];
    if (roundLowerLeft) {
        [self drawCornerInContext:c cornerX: x_left cornerY: y_bottom
              arcEndX: x_left_center arcEndY: y_bottom_center];

- (void)dealloc {  
    [cornerColor release];
    [super dealloc];

This code is based off of some code I found that draws a rounded rectangle.

Enjoy and let me know if you make an improvements.

Saturday, May 9, 2009

How to Charge for an Application

I'm in a real quandary at the moment. I mentioned a little while ago that I'm working on a new application that is part iPhone app and part web site.

First and foremost, I'm building this application to help patients get better care from doctors. That means I want as many people to use it as possible, because it will mean people are getting better care.

I really don't expect to make a ton of money off of this application, but it would be nice to be re-numerated in some way. At the very least, I need to cover the cost of hosting the web application. I also have a designer who is helping me on this with some expectation of getting paid based on return. I'd like there to be a return to do that.

The quandary that I have is how best to do that.

I've thought about a few options. I'm hoping somebody, somewhere, might be able to give me some feedback on what could work best.

Paid iPhone App, Free Web Site

This model is very appealing because it is the least amount of work for me. Put a price tag on the app and be done with it.

I see a couple of problems with this model, though. First, prices in the app store are so depressed that I doubt I could charge more than a dollar or two for the app. I don't believe my target market is such that I'll make it up in volume.

The second problem is that it will likely reduce the penetration of the application. Remember, one of my goals is to help patients get better health care. I'd hate for a couple of dollars to stand in the way.

Free iPhone App, Basic Ads on Web Site

This would alleviate the concerns about the penetration, as the app is free. However, I'm not convinced that I'll see enough revenue to cover the cost of hosting. Maybe a couple of years ago this would have worked, but today? I'm not so sure.

Free iPhone App, Affiliate Programs on Web Site

This is strongly related to the previous one, but instead of "random" ads, I go find affiliates who will pay better money for more qualified leads. Given my users will be very tightly defined, this is possible.

My concern here is how much time do I have to put into managing affiliate programs? Is this something that is a few days to set up, then self sustaining, or am I going to need to spend time daily on it?


There are other options in there, such as paid app and affiliate programs. There may be other options that I'm not even familiar with. An ideal would be some sort of subscription model, but I have not been able to figure out how that would work.

If you have ideas here, I'd love to hear them. I don't expect anybody to come up with my business plan, but I'd love to here is I missed something.

Thursday, May 7, 2009

Learning is Good for You (I Think)

They say learning is good for your brain. Keep the neurons firing strong, keep the brain nimble, what-have-you.

This has been an interesting year for me. In the last twelve months, I've spent serious time with the following technologies. Some of them, I've never touched before. I think I may be nearing a serious case of brain overload...

  • Groovy

  • Java: Yes, I've used it for 12 years, but it's still a context change, especially with all the libraries.

    • Spring

    • Acegi

    • iBatis

    • JMS

  • HTML: Libraries like jQuery and updates to CSS make it a new game!

    • CSS: It's changed a lot since I last used it!

    • jQuery JavaScript the way it should have been.

  • ReST

  • BungeeConnect: I still wish them the best of luck.

  • Objective C

    • The iPhone SDK

    • Sqlite3 C API

  • Python

    • Django

    • SciPy

    • NumPy

  • Flex

    • Flex Data Services

    • ActionScript 3

  • SQL Sybase is the flavor of the month.

On the one hand, I can't imagine being the type who didn't want to keep learning and trying new things. On the other hand, sometimes it would be nice to not think about this stuff for a while. But I still want to become learn Emacs lisp, Haskell, and Ruby. Oh, and I want to find the perfect project for Erlang, too.

Overall, I think I'm spending too much time in front of my computer. Maybe it's time to write a Photoshop plugin so I can force myself to pull out my camera. :) Hmm, maybe I can write a filter that will parallelize nicely across multiple machines using Erlang.

I might even have time for it if I could reduce my Hacker News (good, insightful comments) and Reddit (a sense of humor) time.
Image provided by Clipart from

Tuesday, May 5, 2009

Pearls From Multiple Languages

I've long been a proponent of learning multiple languages. While I have no empirical evidence, I do believe that it gives a market advantage in understanding how best approach software problems. Peter Norvig agrees and Steve Yegge seems to agree, given the amount of time he spends discussing different languages. I'll try to ride on their laurels, since they are way smarter than I am.

Just saying it is a good thing doesn't mean much if you can't specifically say what is good. Very briefly, here are some thing I've learned as I've learned different languages. I am not saying that I'm an expert at all of these languages; in fact, in many cases, it's the opposite. However, I have spent enough in them to gain some pearls of wisdom for my career. These pearls, taken together, have made me a better developer.


I included it, because through it came my first understanding of loops and basic programming constructs: the wonders of GOSUB. Yes, my BASIC pearl was, in fact, GOSUB.


Pascal took all those hand-rolled constructs from BASIC and formalized it. My pearl was that, when put into the native constructs of a language, the constructs learned in BASIC were much more useful and usable.


My pearl here was understanding how the metal works. Understanding that those thirty variables sitting in your function have to be swapped in and out of a limited number of registers was an important lesson. I wonder now, though, whether that lesson is as important today as it was when I was learning Assembly 15 years ago or if compilers have largely made this learning irrelevant. Still, it surprises me how many people don't understand why 1.1 cannot be represented in a native float type.


Once upon a time, it was the college teaching language. To be honest, I had a very difficult time with it. As I struggled to build a Pascal interpreter in Scheme, the pearl I learned was that all languages are equally powerful. It just so happens that some languages are more expressive in ways that are important for particular problems.


What can I say? The workhorse of systems programming. As I played with making code compile on various systems, the I learned was that it is possible to write close to the metal in a more abstract, efficient way. The pearl learned was that languages provide many trade-offs, and it is important to understand what you are trading when you choose a language.


C++ was my introduction to object oriented programming. While that could be pearl right there, it wasn't. My pearl came when I realized that a large team could effectively work together using the structure that object oriented applications created. While this is undoubtedly possible with other programming models, it felt right with OO.


I started using Perl as my first foray into web development. I had played around with shell scripts, awk, and the like for several years; but Perl was light-years ahead of those. My Perl pearl (don't pardon the pun...) was that a scripting language could be not just as powerful as a compiled language, but, in some ways, more powerful.

Visual Basic

I debated admitting to this one, but I did find a pearl here and it's an important one. I was working for a company building CD-ROMs and for this project, time was of the essence. Given the form-building capabilities of Visual Basic, I could build the application very quickly. The pearl: focus on the business objective and not the technology. Even though the technology was...umm...sub-par, the business objective was successfully met.


I have a love-hate relationship with Java right now. I've learned more about how to develop software while writing Java than any other language (because I've written so much of it), but the language has not aged well (unlike the JVM, which has aged marvelously!). Ironically, given how strongly typed Java is, the pearl I learned from Java is that you don't always have to know the type (think Collections before [evil] templates).

JavaScript / ActionScript

I've had a long history with JavaScript, starting with simple browser manipulations to building a significant Flex application. Interestingly enough, my pearl here comes from comparing JavaScript as I've used in the browser to ActionScript that I've used in Flex (both of which are flavors of ECMAScript). The pearl is that, when you've got something good, it is OK to leave it alone. I'm watching ActionScript turn into Java and, frankly, not enjoying it.


It is funny how people love or hate Python, and most of it seems to come from significant white-space. I'd be lying if I didn't admit to needing to get over that as well. Once I overcame that, though, I gained my pearl: If you can write concise, readable code, you can introduce fewer bugs and be more efficient.


Erlang is a great language. I wish I had an opportunity to use it more. I honestly believe it could go a long way to reducing the difficulties so many developers have with multi-threaded code and so many systems have with scaling. And that, really, is my pearl: sometimes the tools we use are a variable in how tractable a problem is to solve.


These tid-bits do not encompass all I've learned from these languages. They do highlight what I consider to be key learnings I've taken from them. More important than any single pearl is the combination of unique pearls the whole gives.

I've also learned a few other languages over the years. My latest excursion is Objective C, which I can't say I've used long enough to gather my pearl yet. I'm sure it's in there somewhere, and I'll keep looking until I find it.

My point in this is two-fold: First, no matter what language you are "stuck" with at work, there is value in learning other languages. These pearls will make you rich.

Second, if you haven't found a pearl yet, keep looking. Try to find it, because the exercise of looking for your pearl is where all the value is.