Surf Roots, Software Thoughts

I wanted to say more about viral sites. I think there are two really cool features that can be implemented to improve your SEO and also utilize the Blogosphere more.

Widgets - get people linking to you
Offering widgets makes it very easy to get people to link to you. For example, I could create a widget for Best Seattle Bars that allowed people to drop some code on their site and display a list of the best Seattle bars. I could also create a widget for Best Seattle Bars that allowed people to drop some code on their site to display a search box. The two best advantages of using widgets are 1) you get people to link to your site, which improves SEO and also increases referrals, and 2) you get to control the way that people link to your site. Here are two examples of widgets that Trulia, a Redfin competitor, offers:

Pretty nifty, huh?

Trackbacks - encourage bloggers to link to you
Bloggers love to blog. If you have rich content on your site such as homes for sale, restaurant reviews, or travel tips, then chances are good that bloggers are already blogging about you and linking to home, restaurant, and travel pages. Reward them and maybe they’ll blog about you more. Setup a mechanism on your site to capture trackbacks sent by blogs, and put a link on the page that’s being linked to, linking back to the blog post. On Best Seattle Bars, an example would be to put a link to each blog post that links to a particular bar page at the bottom of that bar page. You would probably want the link to be nofollow, but bloggers would still get referrals from these links.

The largest factor of PageRank is link analysis, so the more people that link to you, the better you’ll perform in search engines.  The better you perform in search engines, the more people you’ll get coming to your site.

As I begin to count down to my time in China, I’m starting to learn a lot more about the language and the culture. I’m creating a new “China” category that will contain posts about my time leading up to China and also about my time in China. I’ve labeled the category “China” instead of “Shanghai,” because I plan to travel a lot while I’m gone.

Here’s the feed for the category

Bonus story: learning Mandarin Chinese is hard.

I’ve been trying to get certain HTML tags to not be filtered by WordPress, and I found a good article that explains how here.

Coding horror just wrote a nice post that goes along well with all of the things I’ve said about understanding your users. They make a few claims that I disagree with, such as

Listening to users is a tricky thing. Users often don’t know what they want, and even if they did, the communication is likely to get garbled somewhere between them and you

But the post has a strong message. Take a look.

Update: here’s a response post.

I was just looking through my Google Analytics reports and noticed that people were accessing my blog with some interesting keywords. Check it out:

• weed in whistler (9th result)
• getting weed in whistler (1st result)

Each of these results links to my post about the idiot that lied to me and brought weed in my car.

A while back I wrote a post that explained how Network Solutions would steal your domains if you used their site to search. Techcrunch just wrote that they’re getting sued. Hopefully they get what they deserve. Assholes.

I’ve always been annoyed by people accessing my sites without using www (i.e. requesting cellarspot.com instead of www.cellarspot.com). This is annoying because it can hurt SEO and it also confuses Google Analytics. I’ve found a fix!

Using Apache mod_rewrite you can create a rule as follows, either in httpd.conf or in a .htaccess file:
Options +FollowSymLinks RewriteEngine on RewriteCond %{HTTP_HOST} ^yoursite.com [NC] RewriteRule ^(.*)$ http://www.yoursite.com/$1 [L,R=301]

I’ve been a product manager (PM) at Redfin for almost a year now, and I’ve learned some really valuable things. My bosses, a lead product manager and the director of products, have been incredible mentors, and I wanted to share some of the advice they have given me along with some of the things I have learned along the way. I also wanted to highlight a few points from a book that also helped me learn how to be a good PM, though I’m not sure if I’m a good PM ;).

Research
When you’re designing a product, you need to research. I’ve talked about this a lot in previous posts, so I’ll summarize my previous post very quickly. You need to understand your demographic, and you need to understand the problem that you’re trying to solve. If you don’t fully understand your problem, then you’ll very likely create an unsuccessful product. Talk to your users anyway you can – over coffee, via online surveys, via focus groups, etc. I can’t begin to explain how important this is. Do it! I didn’t research Cellarspot enough, so I designed a website that is barely used.

Documentation
The type of documentation that you’ll have to produce really depends on the situation. Generally speaking, if you’re at a larger company, then you’ll probably have to publish documents about the business requirements of a product, the specifications of a product, and the ways in which a product will look (wireframes). If you have to draft these documents, then think critically about their audience – will programmers be reading this? Will executives be reading this? Etc. Make sure you get these documents reviewed by a peer prior to sending them to your boss.

If you’re at a smaller company, then you probably won’t have to document things as much. I’ve heard of certain startups drawing wireframes on the whiteboard, taking a picture of it and writing a quick description of the features, and then sending these two things off to a developer.

Generally speaking, I think it’s far more agile to draw some whiteboard wireframes, write some quick descriptions, and then send these off to a developer. However, I do believe that documentation is very important. Documentation facilitates review, and I believe that review is usually a good thing. That’s not to say that documentation is necessary for review, though. Documentation also makes it easier for a developer to mimic your vision of the product. I would document things if I were told to, and I would decide on a case-by-case basis whether to document or not if I were to make the decision myself.

I’ve written a lot of documentation at Redfin, and I believe that most of that documentation was necessary. There have been certain times when I thought the time spent on a certain document was wasted, but for the most part I agreed with the decisions my bosses made to document things.

Working with Others – Meetings, Reviews, Etc
As you’re researching, documenting, or just thinking about the product you’re trying to build, you’ll work with other people. Depending on the company, you might be in constant iteration with your boss. Regardless of the company, you’ll have to hand things off to a developer and speak to at least a few people about what should go into the product. Be prepared to be in charge of these interactions. You’re in charge of managing this product, so be prepared to be in charge of meetings, reviews, etc. You should be prepared to do a few things. First, be prepared to explain your current thoughts and ideas. Be prepared to discuss alternatives. Be prepared to ask questions, and make sure that the questions you ask are well-formed. Be prepared to be in charge of organizing meetings, and be prepared to be in charge of making sure those meetings move towards a solution. More to come on what to be prepared for …

Your Idea and the Alternatives
While designing your product, you’re going to run into a few forks in the road, where there are a few different options and only one option can be chosen. Go into meetings with a choice and reasoning for your choice. In my meetings with our CTO, I would present all the options and brainstorm them while in the meeting. I should have brainstormed the options on my own time with peers and presented my decision to our CTO with a detailed explanation and reasoning for not choosing the alternatives. It’s very easy to fall into the trap of putting decision making off, so make sure you’re either making good decisions or asking questions that will help you make a quick and good decision.

One of the products I worked on at Redfin was very, very delayed because of the way I interacted with our CTO. I kept expecting him to make a decision with research that I would present to him, when really he wanted me to make a decision and review my decision.

Take charge; make decisions – just make sure the decisions you are making are well thought and that alternatives have been addressed.

Too Much Data … Can’t … Synthesize
When researching a product, it’s very, very easy to get too much feedback. It’s also common for feedback to contradict other feedback. For example, your CEO might say that he or she wants features A, B, and C and not X, Y, or Z, while a customer might say that he or she wants features X, Y, and Z and not A, B, or C. It’s very easy to get overwhelmed when synthesizing research and feedback. When this happens, take a step back and revisit the problem. Clear your head over the weekend or spend a weekday working on something else. Revisit the problem with a clear head, lay all the options on the table, and make a decision. Again, get others involved by presenting alternatives and reasoning.

I organized a meeting with our CEO, CTO, director of products, director of marketing, and a few other people, and I would say that there were at least five contradicting opinions in this meeting. I didn’t know what to do. I wanted to satisfy everyone’s requirements, but there was no way to do so given their varying opinions. I took some time to work on a different product and later revisited this product. I wrote all the options on the whiteboard, made decisions on contradicting opinions, and prioritized the list of features. I’m still worried that the decisions I made might annoy certain people, but I try to remind myself of the following thought. At one point I had all opinions, feedback, and data in my mind, and the presence of those things naturally affected the way I see this product. Even though I may not have incorporated certain opinions in my list of features, I at least incorporated those opinions in my decisions.

Schedules
Often times PMs are in charge or setting schedules. Make your schedules milestone-oriented. Bucket various work items into milestones and set dates for those milestones. Some example milestones are code complete (all code written), content and design complete (all content and design elements have been included in the product), test ready (your product is ready for testing), zero bugs (all bugs either triaged (priorities changed, assignments made), punted (moved to a later release), or fixed), and release to world (your product is launched). Schedules are much more manageable with fewer deadlines, and bucketing work items into milestones makes it easy to have schedules with fewer deadlines.

When picking deadlines for milestones, make sure your deadlines are based off of feedback from the owners of the work items for each particular milestone. Top-down schedules (schedules defined by a PM and followed by stakeholders) are more prone to inaccuracy and generally create a stressful environment. Talk to each stakeholder and ask them how much time they need to finish their work items. Think critically about dependencies as well – often certain work items will depend on other work items, so these dependencies should be included in your schedule deadlines. Once you have an idea of how long a milestone will take, send an email to all of those involved in that milestone and ask for their confirmation. Bottoms-up schedules are more likely to be accurate and also make the PM seem more like a coordinator/leader than a dictator. Bottoms-up schedules are less likely to be rushed, and therefore the quality of your product is more likely to be higher. A possible criticism to a bottoms-up schedule is that stakeholders such as developers, system engineers, and marketing analysts will be lazy and set dates too far in the future. Hopefully you work with people who are passionate about their work, but if they aren’t, then you’ll have to motivate them. More on motivation later …

Schedules are insanely important. Setting schedules makes your product more likely to move forward at the fastest possible rate, especially when the schedule is defined from the bottom up. Spend time creating a schedule, and make sure that everyone involved in the schedule understands it and agrees with it.

Motivation
It’s easy for large projects to drag on and become uninteresting. It’s also common for coworkers to have different motivations. For example, it’s not uncommon that a PM finds a particular feature very interesting and fun, but a developer finds that same feature to be boring and uninteresting. In cases when a stakeholder is uninterested, it’s your job to motivate them. I haven’t had to do much of this at Redfin, but I can make a few speculations. First, be kind, positive, and pragmatic. I’ve seen first hand how one person’s energy can affect those around them. Create positive energy, not negative energy.

Be generous and thoughtful. Bring your team to a happy hour every now and then. Buy your team a nice lunch. Ask your team how their families are or how their weekends were. Again, create positive energy. Tell your team how awesome their work is – how fast their code runs, how beautiful their design is, or how badass their recommendation system is. Also, always ask if there is anything you can do to help.

Take the blame. If something goes wrong and it isn’t clear who is at fault, then take the blame. You might not necessarily be the person who erred, but take the blame anyway and do what you can to right the wrong. Your team will appreciate this, and at the end of the day, it doesn’t matter who is wrong. Taking the blame makes everyone feel better and allows things to move forward.

Perhaps some people might argue that these techniques are all brown-nose-ers. I simply disagree. Compliments are powerful and make people feel good, and people that feel good are more likely to kick ass, even if they’re burned out or uninterested.

In Summary, Be a Leader
Most of the advice I have just explained really comes down to simply being a leader. Lead your team in a positive, thought-driven way, and do the best you can.

Leave me a comment if I’ve left anything out or if you disagree with some of my opinions.

Update: Amit wrote a really good response post here (also in the trackbacks).

This post was written on Monday, February 18, 2008.

I’m writing while in my compact airplane seat on my flight back to Seattle from Denver, Colorado. I spent the last four nights in Boulder visiting my two best high school friends. I had such an awesome time in Boulder that I wanted to share my story.

This plane ride marks the end of my third trip to Boulder, but this trip was exceedingly better than my previous trips. I got some quality time in with my two friends that I miss a lot, and I got a good opportunity to really soak up the town in all of its wonderfulness.

First, the weather
It snows in Boulder a fair amount, and often when it doesn’t snow it’s sunny and relatively warm. This feeling of contrast is as beautiful as the feeling you get when being splashed by a cool ocean wave after laying in the sweltering sun for an extended period of time. You get to enjoy the fun of being snowed on, while only days later you can enjoy a game of shirtless outdoor sports at the nearby park. I love it.

Second, the food. Third, the food
I could name at least 10 different food joints that are open until at least 2:00am. I would say that 80% of these joints offer unique, unbelievable food such as joints (mini-calzones), cinna-sticks, and steak-and-chee (sandwiches). The other 20% offer the basics – pizza, sandwiches, etc. All 100% of these joints are cheap. Dirt cheap. We bought 30 wings, four tacos, and a pitcher of good beer for $25. Boulder is filled with insanely good eats that are cheap and open late. What more could a college student ask for? Oh yeah, most of them deliver.

Fourth, the people
I find myself to be much more like the people that I’ve met in Boulder than the people I’ve met in Seattle. That’s not to say that I don’t enjoy the people around me in Seattle. No. In Seattle I’m surrounded by really good, fun, smart people, and I’m not trying to say that people in Seattle are inferior. I’m saying they’re different, as almost all inhabitants of a unique city are. I’m making the very general claim that I have more in common with the people I’ve met in Colorado. For example, most of my friends in Colorado, new and old, are goofy. They wear cowboy outfits to the cowboy bar, or they make odd gestures while riding the mechanical bull. They dance like morons when no one else is dancing, and they sing along to all the most rocking songs. When I wear my big blue flannel in Seattle, I get referred to as “Lumberjack Alex.” If I wear my big blue flannel in Boulder, I get complimented on how awesome it is. When I sing to a song and play air guitar to a song while in Seattle, I generally get weird looks. If I do the same in Colorado, then I’m usually joined by a collection of my friends in a multi-part, off-key harmony.

Fifth, the skiing
The mountains 90-minutes away from Boulder are great (Vail, Copper, Breckenridge, Keystone, A-Basin, etc). They offer multi-mountain, cheap seasons passes to college students, and most mountains have great terrain. I like Mammoth better, but I think it’s safe to claim that the Colorado resorts are better than Washington resorts (Stevens, Crystal, etc), except for maybe the exception of Baker.

Sixth, the school
The University of Colorado offers so many more services to its students than the University of Washington; it’s disgusting. They have a Buff Bus that busses students around so they don’t have to walk alone late at night in the often-cold weather. CU makes it easy for their students to eat well and get exercise, while the UW doesn’t provide carpool discounts for the gym parking lot past 3:00pm. I feel that these points I’m making are slightly out of scope, so I’ll leave it at that. I will say that my trip to Boulder has motivated me to begin writing a post about ways the UW could improve, so stay tuned for that. And, to UW’s credit, I think its academics are generally better.

If you have friends in Boulder, then go visit them. You’ll have an awesome time in an awesome college town. I definitely did.

Guess what? The following C code compiles with no warnings in gcc with the -Wall option:

void map_equals(void* k1, void* k2) { int key1 = key1; int key2 = key2; } int main() { return 0; }

My partner and I just spent 5 hours debugging the rest of our code only to find out that the assignments were supposed to be assigning from k1 and k2, not key1 and key2. Shit. Lesson learned I suppose.