Tag Archives: product development

Quora: Product Development Board

Quora

Quora

I spend a great deal of time perusing Quora for knowledge. I find it to be both personally and professionally rewarding. I’ve asked and answered questions on a number of topics ranging from cooking to entrepreneurship to technology. Before the holiday break Quora released a new Boards featureset which allows users to do what people do on boards: create topics for discussion based and build a community within that topic. Quora did this before boards by helping people find or ask questions and then contribute, curate and follow the answers other provide. In addition to that, users can vote up or down answers and comment on each. You can even sign up to be a moderator for any topic if you feel so inclined. I find my best contributions are in working behind the scenes to help answers find their way to questions be it through clarification of a particular post or encouraging others to join in.

Today I created a Product Development board on Quora so that I can curate the topic more closely. I invited a couple dozen of my followers to follow the board and encourage anyone who does follow it to post links, ideas, and questions freely. Part of my rationale for doing so is tied to this feeling I have as a product guy in the organizations I’ve joined: isolation. The Product Person’s Dilemma is one I plan on writing more about but it boils down to this: Product Development requires that the product person be multi-disciplinary and weave themselves easily into technology, marketing and design groups within their companies. By doing so, Product people generally stand alone in their company with few others they can talk with to learn from and grow. On the one hand we are social working with many people from many backgrounds. On the other, we generally do not work with other Product people. Unlike CEO’s, CTO’s and CFO’s which have their own groups for managing companies, Product Managers (who are essentially the CEO’s of their products) find few dedicated resources online to compare notes and share best practices with other Product Managers. What resources do exist are often dedicated to Product Managers whose products exist offline. Where does that leave us who develop products for the Web? I have an answer for that….

Posted in product development, product reviews | Tagged , , , , | Leave a comment

The Complete Guide to Google Wave – the eBook published by 3ones

Book Cover

Book Cover

With much pride in our work, we announce the arrival of our first published eBook, the Complete Guide to Google Wave, by Gina Trapani with Adam Pash. It’s the first book published about Google Wave. The book is also free to share. Free as in freedom. Free as in, download, share, copy, recycle, re-mix and re-factor. It’s  yours, yours, yours, and yours. You’re all welcome.

Published the Wiki Way

The guide went live a few weeks ago as a wiki first. Gina and Adam continue to write it and edit it. Which is to say, it’s no longer just a book but a truly collaborative book that exists online. If you buy a PDF copy, download it to your kindle or desktop and enjoy. If someone loans you a copy, do the same. But remember…

Credits:

If you think our work was valuable, show it by contributing to the wiki, buying the eBook, or both.

Watch this Space

We’ll be using our site to tell the complete story behind the Complete Guide to Google Wave. We have planned releasing four editions over the next twelve months. As we explore the economics of this open publishing model during that time we’ll share our insights into the business of book publishing in the eBook/Wiki era.

Enjoy!

Posted in our books, our products | Tagged , , , , , , , , , | 3 Comments

Three Important Things No Product Development Company Can Do Without

People always ask us where the name 3ones came from. Well, here it is.

Simplicity, Stability, Scalability

Simplicity, Stability, Scalability

There are other subsequent trinities that help us keep our wits about us. There are 3 founders to the company: Jon, Trisha and Kelly. There’s the product lifecycle which can be divided into three parts: past, present and future. In digital media, Rip-MIx-Burn represents mashup culture (which helps your product become more spreadable). Teamwork: Learn the ABC’s (Alignment, Buy-in, Completion).

We like to think that all of the variations on the theme of 3ones are essential to our ongoing success. But I came across one the other day that struck me as being essential to the ongoing success of any business.

Community, Work & Family

Community, Work & Family

As we continue to grow as a company, we continue to renew our dedication to the three sectors of our individual lives. In a company, work is a given. Family and community can easily be taken for granted. We are out to prove that we can be dedicated to what’s important. After all, when we build products with a mind for simplicity, scalability and stability – you leave more time for the other important elements in life.

We strive to be happy in our relationships at work, in the community and with our families. Those are our real factors for success. What are yours?

Posted in about us, the little things | Tagged , , , , , | Leave a comment

The Ultimate Taste Test: Validation

Just because the food has gone off it doesn’t mean you have a bum taster. On the contrary, your tastebuds are doing what they should. So what does taste testing have to do with product development?

When tests fail, the test is doing its job. Finding “fails” fast is why we create tests in the first place. This is why we validate.

I recently had a conversation with a client about why validation exposing “fails” should not be seen as application failure per se. It exposed a couple of misconceptions non-developers often have of the development process. It took a while to get my point across. I guess you can say this logic is an acquired taste. One that comes from years of developing products.

Some of those misconceptions are described below.

Code should be perfect.
Not all code can be perfect. In fact, often code is imperfect. Even if it’s flawlessly executed, it may in fact solve a different problem than the one we expected it to solve. Such code cannot be classified as “buggy.” It can, however, be classified as producing unintended results.

When tests fail, the code being tested is “buggy.”
Not necessarily. When tests fail, the only proof is that the test is producing the desired result – not necessarily that the code is buggy. The code could be doing exactly what it was designed to do. But the result, being unexpected, helped us uncover how the application should be coded differently.

Once we realize the flaw in the application design, it’s always worth it to “fix” the problem.
Not so. It wouldn’t make sense to fix things that only affect a small percentage of users. These edge cases can be so seldom that certain levels of risk in failure rates become acceptable.

All technology questions have technology answers.
Again, not so. In order to choose to fix a problem, we must first assess it. A management question arises: how much risk are we willing to accept? How much work will this take? What does that cost? What’s the upside once the work is complete?

“Fixing” the “problem” is the only real solution.
Adaptation is often a suitable alternative to re-writes. Many types of applications are designed to be flexible enough to handle “errors” elegantly and themselves become handy workarounds to “problems.”

What happens very frequently in our business is that products are created and expectations are either met or not met based on what’s created. Perfection for both the entrepreneur and the programmer or goals we expect to attain. However perfection is asymptotic. We can never have the perfect business. By the same token, it’s impossible to build the perfect product. If I buy a bottle of wine, it’s based on a number of factors. Quality is only one of those factors. Price, convenience, prestige, color, varietal, region, all factor into the decision. For the vintner, the challenge is always not to make the perfect wine (though a laudable goal that may be) but to price it correctly given the other factors inherent to it. If its tastes don’t meat the vintner’s expectations but that doesn’t mean the bottle’s bad and can’t be sold.

Bon appetit!

Posted in lessons learned in the trenches, product development | Tagged , , , , , , | Leave a comment

Fail Fast – The Lunchbox

I am going to be giving my first talk on the concept of failure as a means to success in the product development process on Monday. I haven’t produced my deck yet and believe me when I tell you that I’ll be cramming for it. Come see me sweat!

Thanks to Samir Bhavnani (an expert defenseman on my Sunday soccer team) from WorldWineGroups for setting this gig up for me with the San Diego Social Media Club. The event will be at Veoh at 6PM Monday night. Their offices are in Sorrento Valley. A full description of the talk and ticket purchase here.

Posted in about us, lessons learned in the trenches, product development | Tagged , , , , | Leave a comment

25 Things – Tending the Walled Garden


All kidding aside, the 25 Things Meme is a big story and it’s clearly got a lot of coverage. Compete.com revealed that the meme was single-handedly responsible for the biggest single month of traffic increase in the history of Facebook (both in quantity of pages views and in percentage of growth). It also happened to coincide with Facebook finally getting more pageviews in a single month than MySpace in North America. That’s the buzz. But there’s more to it than meets the eye.

From a product perspective, Facebook is quickly lowering its appeal to me. Espespecially because of this meme. It used to be that Facebook was essentially spam-free. That it was a safe haven from emails from uninteresting or un-solicited junk mail. While I (and only I) might be fascinated with my Uncle’s golf swing I am not really interested in him asking me to share it with others. That’s the finer point of social networking netiquette, I realize, but still. It’s a spam thing. It’s a chain letter from a friend.

Facebook has taken measures to prevent spam in its applications in the past (a year ago, nearly). The precedence for them limiting the unintended downside of social networking. But this kind of spam will be harder to prevent. What’s more, the barrier to entry on this is so small for notes. While there may be 600,000 application developers capable of creating a viral effect in their application, there are 150,000,000 Facebook users who can author the next Note meme. 

That sound you just heard was the sound of 149,999,999 UGH’s. 

 

The Next Great Meme?

The Next Great Meme?

 

So, the question remains: What is Facebook to do? 

As a product developer, I would discourage my clients from Facebook’s current (seemingly deliberate) silence on the subject. For the amount of traffic they generate, their blog is clearly not used as a promotional mechanism, but as a strict Public Relations broadcast tool. They really don’t encourage dialog. But then again, nor does google, yahoo, AOL or MSN. When these companies are ready to reveal something (such as a change in privacy policy, or a new partnership), they first mention it on their blogs. They get feedback and, barring any mass upheaval, go ahead with the plan as stated. Facebook has a precedence for both changing their minds after getting feedback on their blog. Sans announcement, there is only one recourse for the facebook community: taking it to the Web.

The irony here, of course, is that Facebook as a product is a walled garden. It’s the new AOL. By having a walled garden, Facebook is taking on the task of policing the territory as well. In seeking to become a “platform” for the Web it must face these challenges head on (and responsibly). As it gains marketshare, how it deals with the unintended consequences of its product experience will become more important. It comes with the territory, not just the product. Ask Microsoft and Ma Bell. But if they’re going to address it, they need to do so at the product level. Whether or not you want to announce the change is another story. 

My Recommendations?

  • Limit the number of people that can be added to a note in a single take.
  • Limit the number of people that can be added to a photo.
  • Give users who, like me, prefer not to be added to notes, the choice to be automatically opted out. 

What do you say?

[poll id="3"]

Other coverage:


Posted in Uncategorized | Tagged , , , , | 1 Comment

"Failure" is the New "Success"

My latest Lifehacker post (“Failure is the Highway to Success“) is about my personal experience “failing” at growing Dandelife. I’m noticing a lot of people have the same thoughts. I guess you could say there’s something in the water. In a down time, it’s only naturual to collect your thoughts and carve a new path for yourself. Ahem, 3ones, ahem. :-)

Posted in lessons learned in the trenches | Tagged , , , , , , | Leave a comment

Fail Fast & Other Product Development Lessons Learned in the Trenches

I spoke at a San Diego TiE event at the end of January. It was a panel of Software Entrepreneurs fielding questions about what the start-up life is like in software these days. Steve Bjorg from MindTouch was there. The two other panelists were Thomas Carter, Founder & CEO, Capital Window  and David Desch, Vice President of Engineering and IT, Digital Force Technologies (he helped Sony launch their HDTV division). For me, the chance to speak at the event was well worth it. I had not a little bit of fun too. In every way, I was the anomaly up there. No success to speak of (in the monetary sense), no “team” and no inhibitions.

Aside from being fun, the event also helped me frame some thoughts I’ve been having. I thought it would be a good idea to get them down on paper while they are fresh and share wit you. Let me know what you think, yeah? [...]

Posted in lessons learned in the trenches, product development | Tagged , , , , , , , , , , , , , , , , , , , | Leave a comment