Thoughts from my journey

I recently read Ben Horowitz’s piece on the importance of training people in startup companies. At the end of this article he put together a document “Good Product Manager, Bad Product Manager”. Here’s my spin on it: Good Developer, Bad Developer. Enjoy, I look forward to your comments!

Good Developer, Bad Developer

Good developer is an artist, a craftsman who enjoys the process of creation. Bad developer considers himself as a programmer, responsible for generating lines of code.

Good developer understands the problems of the customers. Bad developer understands only the technical problem at hand. Good developer does not define the why, but constantly strives to understand why. He’s responsible for the how, and still sees the big picture. Bad developer is focused on building classes and methods and configuration files, but does not get the big picture.

Good developer understands the complete architecture of the product. Bad developer knows only the components he’s written. Good developer fully understands the technologies that are used within the product. He understands what they are used for, and how they work internally.

Good developer is not afraid of new technologies but embraces them by quickly getting a grip. Bad developer only sticks to what he knows. His immediate reaction to any technical change is negative.

Good developer is constantly learning and improving his skills. Good developer reads technical articles, and finishes several technical books a year. Bad developer does not have time to learn. He’s always too busy with other stuff.

Good developer cares about the product quality. He is also very much concerned with the process quality. Good developer pushes himself to create bug-free code; bad developer leaves it to QA to find bugs to fix.

Good developer develops features which create value for customers. Bad developer completes tasks. Good developer will never claim the requirements are incomplete, and will make sure to fully understand the features he’s working on. Bad developer will wait until the finest details are available. To emphasize: good developer is the CEO of the feature – he’s going to make sure he always has the information needed to accomplish the feature, and in case information is missing he’ll make sure he gets it.

Good developer is not afraid to go into anyone’s code. Bad developer is afraid of others looking into his. Good developer understands that it shouldn’t take more time to write self-explanatory and well-documented code. Bad developer always needs to allocate extra time to document and simplify.

Good developer will never feel his code is good enough, and will always continue to clean and fix. Good developer always strives to create elegant solutions but understands that his job is to deliver value to customers. Bad developer thinks only about the elegance of his code and leave the job of delivering value to others.

Is that all? Did I miss anything or got some of these wrong? Feel free to chime in the comments below!

Guy Nirpaz
Co-Founder & CEO, Totango

Two days ago I had the pleasure to tell the story of Totango to Justin Vincent and Jason Roberts of Techzing. Techzing is very active podcast for hackers. Jason and Justin operate in the space and also cover it on their show which makes their questions and interest really genuine.

Justin started to experiment with Totango by integrating his successful enterprise twitter platform Pluggio into Totango. BTW, if you’d like to see great implementation for ramping up customers on a non-trivial service, I would highly recommend to subscribe to Pluggio.

Please listen to the show and let me know what you think?

Here it is TZ Inteview Guy Nirpaz / Totango

The phrase in the title is not original, I admit. (The original discussion is about the future of internet marketing and advertising, see here)

Hiring great people and building great teams is not trivial. However, there is one very simple rule I follow about hiring  great talents: good people like to work with good people!

Also, talented people are looking for specific jobs, It is not just about the benefits, and in many cases it’s not about the benefits at all (although, I think that there should be an upside for all the hard work being put). People are looking for challenges they would like to tackle, either or both product challenges or technical challenges. Many people I like working with are passionate about what they do and consider themselves fortunate to have the opportunity to professionally do what they love, make meaning and grow personally.

Good people don’t look for jobs on a ‘first come first served basis’, they know what they would like to do next and identify a good opportunity when they see it. Usually they put their eyes on specific companies/roles/challenges they’d like to do.

The best sources for great talent are people you’ve worked with before and know already what they are capable of, the second best source for good candidates comes from references by friends and business colleagues. The worst (and most expensive!) source for recruitment is resumes from recruitment agencies (paid resumes). Very similar to web leads and traffic sources – organic is best, paid is worst.

There isn’t a single activity you do to build a pipeline of excellent candidate who will want to work for you. You should continuously spend your energy in helping the people you’d like to work with find you. This includes social networking online and offline. In addition, you should create value by blogging, sharing presentations, organizing working groups, etc. These all help other learn about what you do and how.

When analyzing our team at SaaSPulse (soon to be rebranded), I find:

• 30% – Had prior working history with
• 40% – Referred by our friends
• 30% – Through social activity

Together with Ori Lahav, founder and CTO of Outbrain we came up with term ‘Inbound Recruiting’. It simply works and helps you build great team.

And of course, If you find this the right point in your life to look for new challenges, I’ll be happy to talk!

Getting a good product visual design is not a trivial task neither working with graphic designers. The product design progresses over time as more learning is being added, while changes needs to implemented fast.

When I first started to interview free-lance designers and designer firms to work with us at Totango I didn’t know a lot about what I’m looking for and how to define it. I wasn’t clear on the requirements and I confused those designers I met with.

My intention was simple (too me), I wanted a modern, clean and user centric design for the product. (Who wouldn’t want that?)

Through the process I learned how to create an aesthetic product design while working effectively with my designers. I’m happy to share with you my tips.

Communication

Most of us grew up in engineering, product management or marketing. We didn’t go to art schools and were not born with the right terminology, so for this reason it’s critical to work on communication with your designers from day 1. To objective it to make sure you’re able to clearly articulate what you want and for the designer to understand and follow you’re guidelines, while still keeping artistic freedom for innovation. More on the next point. Face time (or phone time) is mandatory for that matter. The second aspect which makes breaks communication barriers is to work in small incremental iterations, see next.

Iterative Design

Some design firms will limit the number of iterations to 2 or 3 in order to save labor cost. This is totally wrong! I created a new engagement with my designers where we’re working by a bi-weekly fixed contract. The reason is to be able to iterate as much as possible while nobody looses. The only way I found effective to work together and develop a common langage is for the designer to create a mockup quickly (few mockups per day) so I can comment and push the process forward. It’s faster, it’s more effective and it’s fun, as designers look for feedback fast and early before moving on.

Incremental Design (No Concept!)

In a lean startup, one of the key traits of the startup is it’s ability to pivot and switch concepts. The user interface, as being in front of the customers, will change most. So, there is no point in a contract based on a single concept (as some design companies want), as concepts change/shift over time and the design should support it. In addition, you don’t have enough information to feed conceptual design at the beginning.

By following these three concepts, building a common language, iterating fast and a lot, and working towards incremental product design, I was able to invest just what it needed to create a product design which was always aesthetic and professional and meets the current state of the product and company learning.

I hope this tip will help you, and I wish I knew this a year ago, once I started my journey, as it would have helped me a lot.

One last note, if you enjoy tips like this, please let me know, and I’ll be happy to share more.

I assume you understand the term MVP and the value of putting the minimal set of functionality in front of customers in order to get as much feedback as possible. If not, please have a look at this presentation and come back once you’re done.

Most people don’t argue with MVP principles, however some people find it hard to follow in practice.
In my experience, defining the following is all that you need to make your first MVP step:

• Define a viable vision
• Define the go-no-go criteria
• Define the minimal customer commitment level
• Choose appropriate media

These four concepts are all that you need to take your first stab at MVP:

Define a Viable Vision

Before starting any process of MVP validation, you  need to have a properly articulated product vision. The product vision should include: problem definition, target market, high-level definition of the offering, buyers/influencers, channels to the market and pricing.

Actually, this isn’t exactly part of MVP, however, MVP is a means to an end, and the objective is to get to a product/market fit. The basic assumptions you think will get you to product/market fit, are the ones you’re trying to validate with the MVP approach.

Alistair Croll, calls this Minimum Viable Vision (MVV), and you can read about it here. I call it, viable vision – are you building something which someone really cares about.

Define Go-No-Go Criteria

Before even doing anything, make sure you understand the validation you’re trying to get, and how will you know you’re there. You can be in a very problematic state if you’ve implemented something, and you don’t know how to analyze the feedback you’re getting. So, make sure you define in advance a positive scenario (Go) and negative scenarios (No Go).

For example, we’ve defined a positive scenario that once we show our product demo (minimal) to potential customers, a positive out-come is that they request username and password to experiment on their own, and a negative outcome is if this doesn’t happen. Luckily for us, most potential customers wanted to continue forward, hence validated for us the value provided by the product demo.

Customer Commitment

The quality of potential customer’s feedback is directly related to their level of commitment. Simply put, a paying customer is the absolute truth that your product is valuable to someone. This is the truth we’re trying to get by running MVP. Each validation step should also be validated by the level of commitment by customers.

For example, if you present your product idea to a potential customer and hear from the customer that, yes, they have this problem your product solves and it’s very critical for them to solve it. You should ask this potential customer to be an early user of your product, however, if they refuse to do so (“not now”, “we have other burning issues at this point”…), you should weight their positive response accordingly. The fact that their not willing to commit, puts a different weight on their verbal feedback. For this reason, it’s important to make sure customers are acting in their feedback – clicking a link, putting their email, filling a form, using a product etc.

Media Selection

Ask yourself what would be the best media to put infront of potential customer to get the feedback you’re looking for. In Eric Ries examples, are all web related: web pages, links, banner ads and so forth. In other cases this could very well be a Power Point presentation, mockup screen shots, single use-case demo of an application, etc.

The trade-off is between the time it takes to get a clear answer on the question at hand and the richness of the media. For example, a presentation would work very well at a conceptual level. You can present the problem you’re trying to address in a very clear way and get feedback from potential customers. However, in a presentation it would be very difficult to verify whether the way you’re proposing to solve the problem appeals to potential customers. If you hear ‘no’, we don’t have this problem, or ‘yes we do have this problem, but it’s not a burning one’, you know where you stand.

So, make sure to carefully select the media which provides you richer feedback to minimal investment.

If you have additional ideas on how to make MVP even more practical, please be sure to comment and share.