As a team member of OpenView Venture Partners, I focus all my time on helping the expansion stage software companies in our portfolio produce and release better software product!
Mostly, I provide operational support and advice to our companies' product teams and management, focusing on best practices in product management and development.
I spend a lot of time discussing various situations with development teams and with our Senior Advisers, Jeff Sutherlad, co-creator of Scrum and Agile coach and thought leader, and Luke Hohmann, CEO of his own consulting company, Enthiosys, and product management coach and thought leader. I also attend conferences on topics related to Agile and product when I have the chance.
From these experiences, I try to glean some take-aways, and share them on this blog.
A quick bio:
Prior to focusing on helping portfolio companies with product, I spent over 3 years speaking with software company CEO's and researching market sectors, looking for great investments. I did this first as an Analyst at Insight Venture Partners and then at OpenView Venture Partners, which I helped found in 2006. Prior to joining Insight, I interned at UBS in Technology Development for Capital Markets, Equity Research, and Corporate Finance. I graduated from the University of Pennsylvania's Wharton School of Business with a BS in Economics and from the School of Arts and Sciences with a BA in Mathematics, summa cum laude. I am also a Certified ScrumMaster.
For senior management teams of expansion stage software companies, focus is key to success, and to making their lives easier.
If you're a senior manager, you have limited product management and development resources, limited sales and marketing resources, and so on. So it's key to pick a target market, a direction for the product, and go after it with everything you've got (assuming you've validated that it's the right direction with some data and early success).
Otherwise, if you go chasing after multiple target markets, go in several product directions, chase all prospects, you likely won't get very far with anyone in any market.
To illustrate this graphically, here's a picture from a blog on Agile Development methods, titled, "If you chase two rabbits, you won't catch either":
Get it?
This is why OpenView Venture Partners is highly focused only on expansion stage software companies, and nothing else. It helps us be better at identifying the best investment opportunities and then providing unique value add to those companies. Chasing one rabbit is hard enough!
If you're a senior manager, you have limited product management and development resources, limited sales and marketing resources, and so on. So it's key to pick a target market, a direction for the product, and go after it with everything you've got (assuming you've validated that it's the right direction with some data and early success).
Otherwise, if you go chasing after multiple target markets, go in several product directions, chase all prospects, you likely won't get very far with anyone in any market.
To illustrate this graphically, here's a picture from a blog on Agile Development methods, titled, "If you chase two rabbits, you won't catch either":
Get it?
This is why OpenView Venture Partners is highly focused only on expansion stage software companies, and nothing else. It helps us be better at identifying the best investment opportunities and then providing unique value add to those companies. Chasing one rabbit is hard enough!
There has been a tremendous amount of hype around everything "cloud", and anything that might be called "cloud", in the past 12 months.
So when Network World writes a story headlined 'Cloud Storage Lives Up to the Hype', that's saying a lot!
According to Network World, cloud storage can really be cheaper than your current solutions while delivering high performance.
Not surprisingly, they also found that cloud storage -- and cloud services in general -- offers more complexity than one might expect, and approaches to calculating the full cost of ownership are not necessarily obvious, as this chart from the article illustrates:
The article covered several services, including Amazon's S3, Nirvanix, Rackspace, Egnyte, and Nasuni.
There is also a number of early and expansion stage software companies out there that are not covered in the article that should help cloud storage become much more widespread.
For example, Mezeo enables service providers to offer their own cloud storage service, and Twinstrata helps enterprises derive faster performance and better integration from their cloud storage service providers.
Based on Network World's findings, senior management teams grappling with storage costs should look to the cloud, and expansion stage software companies selling cloud computing software should look to partner and integrate with cloud storage providers.
So when Network World writes a story headlined 'Cloud Storage Lives Up to the Hype', that's saying a lot!
According to Network World, cloud storage can really be cheaper than your current solutions while delivering high performance.
Not surprisingly, they also found that cloud storage -- and cloud services in general -- offers more complexity than one might expect, and approaches to calculating the full cost of ownership are not necessarily obvious, as this chart from the article illustrates:
The article covered several services, including Amazon's S3, Nirvanix, Rackspace, Egnyte, and Nasuni.
There is also a number of early and expansion stage software companies out there that are not covered in the article that should help cloud storage become much more widespread.
For example, Mezeo enables service providers to offer their own cloud storage service, and Twinstrata helps enterprises derive faster performance and better integration from their cloud storage service providers.
Based on Network World's findings, senior management teams grappling with storage costs should look to the cloud, and expansion stage software companies selling cloud computing software should look to partner and integrate with cloud storage providers.
All senior management teams, and especially CEOs, at expansion stage software companies have one thing in common: at any given point in time, there is way more to do than there is capacity to do it, and new items are popping up constantly.
Prioritizing issues and tasks is a key aspect of an expansion stage manager's job.
Earlier this week I was having dinner with a number of current and former expansion stage CEOs, including Ratmir Timashev, CEO of Veeam Software, a leader in VMWare backup and VMWare monitoring software.
The question of how a CEO prioritizes everything that flows his or her way came up. Ratmir said, "There is a 2x2 matrix I use. One axis is Importance and the other is Urgency. I focus on the upper left hand box, Urgent and Important, and ignore all else."
Another CEO immediately responded, "That's what General Eisenhower used during WWII and as President of the United States!"
I then received a Wikipedia entry about it the next day. The matrix that's core to the method looks like this:
This is a great way to think about one's activities, whether for a President of the United States or the CEO of an expansion stage software company.
It seems these days that many headlines in the technology industry having something to do with "the cloud".
Yesterday alone, we heard that CA acquired a cloud consulting company, and Novell signed a cloud computing deal with Amazon.
As it often happens when a term becomes popular, the word "cloud" is being used with an increasingly diverse set of definitions and context.
After all, if you're an expansion stage technology company doing something mildly related to cloud computing -- or something that can be spun as such -- it makes sense to say you're a "cloud vendor" for the sake of competitive positioning.
As far as I can tell, people are widely using the term "cloud" in the following ways:
The good news is that aside from reflecting self-serving competitive positioning statements, the diversity in definitions also reflects the diversity in value propositions of cloud computing.
That is, to some people, the true value comes in flexibility of resources and the cost savings and scaling capability that come with it. To others, it's all about having a common powerful development platform on which to build. And to the less sophisticated buyers, the value is simply in having an application or service hosted somewhere else, so you don't have to worry about the infrastructure. To them, it doesn't matter whether it's a true cloud or a regular data center.
This is one of the reasons spending "in the cloud" continues to increase, why new vendors continue to pop up, and why OpenView Venture Partners continues to be interested in the space.
Yesterday alone, we heard that CA acquired a cloud consulting company, and Novell signed a cloud computing deal with Amazon.
As it often happens when a term becomes popular, the word "cloud" is being used with an increasingly diverse set of definitions and context.
After all, if you're an expansion stage technology company doing something mildly related to cloud computing -- or something that can be spun as such -- it makes sense to say you're a "cloud vendor" for the sake of competitive positioning.
As far as I can tell, people are widely using the term "cloud" in the following ways:
- A combination of computing and storage resources available as an on-demand utility, allowing you to dynamically scale up or down based on your needs as they very rapidly.
- A hosted application as a development platform, allowing developers to actually develop (some people believe an API is the minimum requirement).
- Anything hosted by a 3rd party vendor! So if you're an old-school hosted e-mail provider with a regular data center, now you're offering "e-mail services in the cloud".
The good news is that aside from reflecting self-serving competitive positioning statements, the diversity in definitions also reflects the diversity in value propositions of cloud computing.
That is, to some people, the true value comes in flexibility of resources and the cost savings and scaling capability that come with it. To others, it's all about having a common powerful development platform on which to build. And to the less sophisticated buyers, the value is simply in having an application or service hosted somewhere else, so you don't have to worry about the infrastructure. To them, it doesn't matter whether it's a true cloud or a regular data center.
This is one of the reasons spending "in the cloud" continues to increase, why new vendors continue to pop up, and why OpenView Venture Partners continues to be interested in the space.
I recently came across a blog on 10 steps to successful marketing using Agile. All the suggested steps are good ones for marketing teams and any project oriented team at an expansion stage software company, be it for product development or a website re-design.
A few years ago, I led the implementation of the leading Agile Development methodology Scrum at OpenView Venture Partners. Specifically, we used Scrum to execute operational support projects for the expansion stage software companies in our venture capital portfolio.
We ended up following the 10 steps mentioned in this blog and more. My advice for any team adopting Agile practices outside of product development is to start by focusing on just these 3, and the rest will come.
1. Step 1 from the blog, restated as, "Recognize how your function and unique situation are different from product development, and determine what makes sense for you."
2. Step 3 from the blog, restated as, "Make sure that whatever you end up doing in terms of adopting Agile, you're aligned with the company strategy and goals. Anything else is wasteful!"
3. Step 10 from the blog, "Retrospect, inspect, adapt." Stop at fixed time intervals, look back on what you did, how you did it, and why you did it, and make it better. Whatever you come up with in Steps 1 and 2 will be incomplete or just wrong, so you need to adjust.
The values, principles, and prescriptions in any Agile methodology can be brilliant and have extremely positive impact on whatever function you run. But most of them may not apply to your function and your situation, and all of them do not come even close to capturing everything you need to do in your function to be successful.
So understand the "why" behind each prescription, adopt it as you see fit, make sure you're moving closer to your company's strategic goals, act, stop, retrospect, and repeat.
A few years ago, I led the implementation of the leading Agile Development methodology Scrum at OpenView Venture Partners. Specifically, we used Scrum to execute operational support projects for the expansion stage software companies in our venture capital portfolio.
We ended up following the 10 steps mentioned in this blog and more. My advice for any team adopting Agile practices outside of product development is to start by focusing on just these 3, and the rest will come.
1. Step 1 from the blog, restated as, "Recognize how your function and unique situation are different from product development, and determine what makes sense for you."
2. Step 3 from the blog, restated as, "Make sure that whatever you end up doing in terms of adopting Agile, you're aligned with the company strategy and goals. Anything else is wasteful!"
3. Step 10 from the blog, "Retrospect, inspect, adapt." Stop at fixed time intervals, look back on what you did, how you did it, and why you did it, and make it better. Whatever you come up with in Steps 1 and 2 will be incomplete or just wrong, so you need to adjust.
The values, principles, and prescriptions in any Agile methodology can be brilliant and have extremely positive impact on whatever function you run. But most of them may not apply to your function and your situation, and all of them do not come even close to capturing everything you need to do in your function to be successful.
So understand the "why" behind each prescription, adopt it as you see fit, make sure you're moving closer to your company's strategic goals, act, stop, retrospect, and repeat.
I attended a Boston Lean Start-up Circle meeting last week. This group and many others are part of the larger lean start-up movement, spurred by the writings of Steve Blank, presented nicely by him here.
The framework and advice provided by this movement apply to start-ups and to expansion stage software companies, and in fact I was turned on to this movement by several product managers from the OpenView Venture Partners portfolio.
This meeting had two presenters: David Cancel, who went through this deck, and John Prendergast (David was founder of Compete, Lookery, Ghostery, and is currently CEO of Performable, focused on website AB testing and conversion optimization. John is currently CEO of Blueleaf, focused on personal finance management).
Many interesting topics were discussed -- all of them relevant to senior management teams at any start up and expansion stage software company -- especially those practicing Agile development methodology.
Some key messages that stuck out for me are these:
* The earlier you are in the evolution of your business, the more important it is for you to act and do something to learn. Planning is important, but less meaningful because you don't know much, and all you have is assumptions. It's much more important for you to act and test those assumptions, as quickly as humanly possible. The key is to find the shortest cheapest way for you to test an assumption and test!
* Data is critical, but don't bury yourself in tons of metrics! Focus on the key metrics that show the health of your business and what you want to impact--that's your operational dashboard. Understand your lead-to-sales funnel. And finally, understand how different groups of users behave over time via cohort analysis, described in detail by my colleague Vlad Djuric in his series here.
* There's no silver bullet! There's no recipe for the perfect start-up. All you can find in literature and at talks are tools to help you navigate the difficult terrain of starting and building a company. The rest if up to you.
The framework and advice provided by this movement apply to start-ups and to expansion stage software companies, and in fact I was turned on to this movement by several product managers from the OpenView Venture Partners portfolio.
This meeting had two presenters: David Cancel, who went through this deck, and John Prendergast (David was founder of Compete, Lookery, Ghostery, and is currently CEO of Performable, focused on website AB testing and conversion optimization. John is currently CEO of Blueleaf, focused on personal finance management).
Many interesting topics were discussed -- all of them relevant to senior management teams at any start up and expansion stage software company -- especially those practicing Agile development methodology.
Some key messages that stuck out for me are these:
* The earlier you are in the evolution of your business, the more important it is for you to act and do something to learn. Planning is important, but less meaningful because you don't know much, and all you have is assumptions. It's much more important for you to act and test those assumptions, as quickly as humanly possible. The key is to find the shortest cheapest way for you to test an assumption and test!
* Data is critical, but don't bury yourself in tons of metrics! Focus on the key metrics that show the health of your business and what you want to impact--that's your operational dashboard. Understand your lead-to-sales funnel. And finally, understand how different groups of users behave over time via cohort analysis, described in detail by my colleague Vlad Djuric in his series here.
* There's no silver bullet! There's no recipe for the perfect start-up. All you can find in literature and at talks are tools to help you navigate the difficult terrain of starting and building a company. The rest if up to you.
I attended a talk by Dave Hussman at an Agile Bazaar event a few weeks ago at IBM's offices. In attendance were developers from expansion stage software companies, big established companies, and members of senior management teams.
It was sponsored by a number of software vendors, including VersionOne, an OpenView Venture Partners portfolio company, and the leading tool for Agile software development teams.
His talk was entitled, "Products and People over Process and Dogma."
The people part I addressed in last week's post, In Agile, People Come First!.
Dave spent a good deal of time speaking about the right time to start coding. Dave remarked that many teams that were focused on following best practices process of Agile Product Development were not necessarily focused on the right things.
The mentality was: Give us a story, we'll code it in a short iteration, show it to you, and go from there.
Well, that's all good, but perhaps the team shouldn't start coding just yet. Does everyone on the team understand the story? I mean, really get it? The 'why' and the 'for whom'? How it fits into the bigger picture of the interface, the use case, the product, the user's life?
Has the team done analysis to think through the different ways in which the functionality could flow? The edge cases? What could go wrong?
Has the team thought through the different approaches to implementing the story? How it touches other code and the architecture?
I have seen first hand what happens when Scrum teams, following all the prescriptions of the Scrum methodology, fail to do the above multiple times.
The result?
Software that may meet the acceptance criteria of a story and definition of 'done' at a superficial level, but ultimately has quality issues, behaves in unpredictable ways, and is often not delivered on time.
So if you're a software developer, the next time you're about to start writing code, ask yourself: Am I really ready?
It was sponsored by a number of software vendors, including VersionOne, an OpenView Venture Partners portfolio company, and the leading tool for Agile software development teams.
His talk was entitled, "Products and People over Process and Dogma."
The people part I addressed in last week's post, In Agile, People Come First!.
Dave spent a good deal of time speaking about the right time to start coding. Dave remarked that many teams that were focused on following best practices process of Agile Product Development were not necessarily focused on the right things.
The mentality was: Give us a story, we'll code it in a short iteration, show it to you, and go from there.
Well, that's all good, but perhaps the team shouldn't start coding just yet. Does everyone on the team understand the story? I mean, really get it? The 'why' and the 'for whom'? How it fits into the bigger picture of the interface, the use case, the product, the user's life?
Has the team done analysis to think through the different ways in which the functionality could flow? The edge cases? What could go wrong?
Has the team thought through the different approaches to implementing the story? How it touches other code and the architecture?
I have seen first hand what happens when Scrum teams, following all the prescriptions of the Scrum methodology, fail to do the above multiple times.
The result?
Software that may meet the acceptance criteria of a story and definition of 'done' at a superficial level, but ultimately has quality issues, behaves in unpredictable ways, and is often not delivered on time.
So if you're a software developer, the next time you're about to start writing code, ask yourself: Am I really ready?
There are two primary reasons I've seen software development teams fail even when they adopt Agile development methods and associated best practices process:
- Lack of clarity or business case on the product being built, that is, what to build?
- Lack of attention to having the right people with the right level of experience and skill level playing the right roles on the team.
For some reason, some senior management teams think that once they've "adopted Agile" -- because people self-organize -- they don't need to worry about anything anymore.
And yet, the first value of the Agile Manifesto is: Individuals and interactions over processes and tools.
Adopting Agile won't make inexperienced or unskilled developers build good software.
Gojko Adzic summed it up, although a bit harshly, in his blog recently, titled, "How to do agile when you have 50 crap developers?".
He rightly poses the question: Why do people, complaining that they can’t do agile development with 50 crap developers, not see that the problem is in the second part of that statement, not the first?
I recommend that you check it out.
Before you worry about getting Scrum practices exactly right, be sure you have the right people on your team!
No matter how large your data center, how much disaster recovery planning you do, how much replication and fail-over hardware and software you have, how many monitoring tools you have, what best practices process you use, or how many people you have, if you're hosting applications, you will have unscheduled downtime.
As a SaaS / Cloud vendor, everything you do is risk mitigation, but you cannot have complete certainty -- whether you are an expansion stage software company or Google.
This is a fact that senior management teams of SaaS and cloud providers and of their customers should never forget.
It is a fact nicely illustrated by CRN, with their review of the 10 Biggest Cloud Outages of 2010 (So far). Oh the fond memories...
On the flip side, this means opportunity for entrepreneurs in data center management and disaster recovery, since uptime can always be improved, and new software tools to help can (and will) still be developed.
As a SaaS / Cloud vendor, everything you do is risk mitigation, but you cannot have complete certainty -- whether you are an expansion stage software company or Google.
This is a fact that senior management teams of SaaS and cloud providers and of their customers should never forget.
It is a fact nicely illustrated by CRN, with their review of the 10 Biggest Cloud Outages of 2010 (So far). Oh the fond memories...
On the flip side, this means opportunity for entrepreneurs in data center management and disaster recovery, since uptime can always be improved, and new software tools to help can (and will) still be developed.
Even if you implement Agile development methods and a best practice process for quality assurance, there is still a chance that your software product will go out with a critical defect that your customer will discover in a bad way.
This can happen to big companies like Microsoft and to smaller expansion stage software companies, especially when they're short on both resources and time.
Once the defect is discovered, the development team should of course fix it, and then conduct a root cause analysis to find out why it happened, and put in place counter measures to make sure it never happens again.
But what about the customer?
Two weeks ago, I was on my way to a vacation. I was in Boston's Logan Airport, having dinner and awaiting my US Airways flight -- a domestic connection to a longer international leg -- when my phone rang. The number was an 800 number that I didn't recognize, but I answered it anyway.
It was a US Airways representative. She informed me that my flight out of Boston had just been delayed by 1.5 hours, meaning that I would miss my connection, delaying my trip by an entire day. She asked me if that was an option for me, and I indicated that it was not. She then put me on hold for 5 minutes, and when she came back on, she told me she had re-booked me on a completely different United Airlines flight, with different connections, that would still get me to my ultimate destination -- and only 2 hours later than initially planned.
Fantastic news!
This was in stark contrast to what happened to a friend of mine, who once lost a whole day of his trip because of a delayed flight, and to a couple I met on my trip, who lost an entire day of their vacation because their first flight was delayed. They missed their connection, and their airline didn't even call them.
What does this mean for software companies and their management teams?
First, fix the defect as quickly as possible!
But go the extra mile and turn a disaster into an opportunity to build customer loyalty and word of mouth.
Be sure to understand the implications of this defect on the customer's business. What pain has been caused, if any? Can you do anything about it?
For example, did your software cause the loss of data? Can you do anything to recover that data?
Is the defect preventing a critical workflow from being executed? Can you come up with a temporary work around that which the customer can use while the defect is fixed?
And so on. The key is: Be proactive in understanding the pain, and do what you can to resolve it. It pays.
I told everyone in site about my great experience with US Airways, and everyone was very impressed, especially those people who didn't have as good an experience with their airlines. At the end of the story, people asked, "Who was your airline again?" They wanted to remember.
The original flight delay -- the defect -- didn't even matter anymore!
This can happen to big companies like Microsoft and to smaller expansion stage software companies, especially when they're short on both resources and time.
Once the defect is discovered, the development team should of course fix it, and then conduct a root cause analysis to find out why it happened, and put in place counter measures to make sure it never happens again.
But what about the customer?
Two weeks ago, I was on my way to a vacation. I was in Boston's Logan Airport, having dinner and awaiting my US Airways flight -- a domestic connection to a longer international leg -- when my phone rang. The number was an 800 number that I didn't recognize, but I answered it anyway.
It was a US Airways representative. She informed me that my flight out of Boston had just been delayed by 1.5 hours, meaning that I would miss my connection, delaying my trip by an entire day. She asked me if that was an option for me, and I indicated that it was not. She then put me on hold for 5 minutes, and when she came back on, she told me she had re-booked me on a completely different United Airlines flight, with different connections, that would still get me to my ultimate destination -- and only 2 hours later than initially planned.
Fantastic news!
This was in stark contrast to what happened to a friend of mine, who once lost a whole day of his trip because of a delayed flight, and to a couple I met on my trip, who lost an entire day of their vacation because their first flight was delayed. They missed their connection, and their airline didn't even call them.
What does this mean for software companies and their management teams?
First, fix the defect as quickly as possible!
But go the extra mile and turn a disaster into an opportunity to build customer loyalty and word of mouth.
Be sure to understand the implications of this defect on the customer's business. What pain has been caused, if any? Can you do anything about it?
For example, did your software cause the loss of data? Can you do anything to recover that data?
Is the defect preventing a critical workflow from being executed? Can you come up with a temporary work around that which the customer can use while the defect is fixed?
And so on. The key is: Be proactive in understanding the pain, and do what you can to resolve it. It pays.
I told everyone in site about my great experience with US Airways, and everyone was very impressed, especially those people who didn't have as good an experience with their airlines. At the end of the story, people asked, "Who was your airline again?" They wanted to remember.
The original flight delay -- the defect -- didn't even matter anymore!
A few months ago, I blogged about security concerns slowing adoption of virtualization.
Given security issues around virtualization, and how key virtualization is to the cloud, it's not surprising that security is now a key impediment to moving applications into the cloud.
Consider a recent CA-sponsored survey on cloud security. It opens with:
"CA and the Ponemon Institute conducted a cloud security survey of U.S. and Europe IT and IT security professionals. The findings show that about half of the respondents don’t believe the organization has thoroughly vetted cloud services for security risks prior to deployment. It also showed that 55 percent of respondents are not confident they know all the cloud services in use in their organization today."
This creates an opportunity for vendors to come up with new tools that help IT managers implement better cloud security.
One recent example is this tool from Fortify Software, which is a vulnerability assessment tool geared especially for vulnerabilities that arise in cloud deployment.
As a venture capital fund that invests in expansion stage software companies in exciting markets, OpenView Venture Partners look to seeing plenty more products and companies in this area.
Given security issues around virtualization, and how key virtualization is to the cloud, it's not surprising that security is now a key impediment to moving applications into the cloud.
Consider a recent CA-sponsored survey on cloud security. It opens with:
"CA and the Ponemon Institute conducted a cloud security survey of U.S. and Europe IT and IT security professionals. The findings show that about half of the respondents don’t believe the organization has thoroughly vetted cloud services for security risks prior to deployment. It also showed that 55 percent of respondents are not confident they know all the cloud services in use in their organization today."
This creates an opportunity for vendors to come up with new tools that help IT managers implement better cloud security.
One recent example is this tool from Fortify Software, which is a vulnerability assessment tool geared especially for vulnerabilities that arise in cloud deployment.
As a venture capital fund that invests in expansion stage software companies in exciting markets, OpenView Venture Partners look to seeing plenty more products and companies in this area.
Last week, I shared 5 issues an expansion stage software company should consider when choosing an offshore, outsourced development vendor for its product development.
Here are five more.
6. Experience with companies similar to yours. Look for vendors that have worked with companies like yours. If you are a US business selling software to financial services company, you want a vendor that has worked with many US businesses on B2B commercial products and, ideally, on financial services software. You do not want a vendor that has only one other US customer, and has focused primarily on B2C software or internal IT applications. If you are an expansion stage software company or a start-up, you do not want a vendor that only has had customers like HP and Microsoft.
7. Best practice & tool adoption. Assess to what degree a vendor is using a best practices process and tool set. More importantly, assess the degree to which a vendor is continuously improving and keeping up with the cutting edge practices and tools out there. You don't want a team that's not taking advantage of the latest industry advanced in productivity and quality.
8. Turn-over. Always ask, "What percentage of employees did you lose last year? The year before that? On x-year projects, how many of the key people that started on them are still there today?" This is key. The last thing you want to deal with is a team that is constantly changing. Constant personnel change means low productivity, possibly defects, and constant re-education by you.
9. Access to the best people. There's a reason the Agile Manifesto that's Agile Development Methods states this as the first value: Individuals and interactions of processes and tools. If you don't have great people on your outsourced team, you won't have great software built with great productivity, no matter what methodology or tools they're using or how mature they are. That's why you need to ask questions about how the vendor sources, recruits, trains, and retains the best developers in their locale. Do they have university relationships? Do they have a special training unit? What benefits do they offer? How do they compare with other companies that hire developers? Who are those other companies?
10. Price. Whatever you do, do not pick a vendor just because they're the cheapest in a region. Also, try to avoid going with the most expensive vendor in a region. The cheapest ones probably do not have the best developers, or have a hard time retaining them. The most expensive ones are probably making too high a margin on you. Try to find someone in the middle. Also, do not negotiate price too aggressively. You want your project to be valuable and financially important to your vendor, so they pay attention to it and resource it well. You don't want to be the lowest margin project that they engaged on because they had low utilization, or the sales guy was trying to meet his quota and got too aggressive. Remember, this is a partnership, so if you "win" a price negotiation, you might ultimately "lose" on getting great software fast.
Last week, my colleague at OpenView Venture Partners, Jeremy Aber, provided 5 Practical Tips for Using an Offshore Software Developer, focusing on legal issues.
This week and next, I want to share 10 practical tips for choosing an offshore software developer (Jeremy and I are quite competitive), focusing on a few other items. Specifically, I focus here on outsourced vendors, and what questions to ask to increase the probability that you -- an expansion stage software company product development team -- end up with the right one for you.
1. Methodology. As you know, there are many different approaches to managing software projects and building software. From waterfall, to 20 different flavors of Agile product development, and everything in between, the methodology the team adopted can impact how it manages the project, how it communicates with its customer -- in this case you -- and how it actually builds the software. You want to understand what methodology the vendor is most comfortable with, and make sure it aligns with your needs, with your own methodology and that of your team. And don't ask, "What methodologies do you use?" or "Do you guys do Scrum?". A good sales guy will list everything under the sun in response to the first question, and answer yes to the second. Put them on the spot with: "I understand you do all that. But which one is the most prevalent in your company and your teams prefer?"
2. Company Size. What's the right vendor size for you? Too small, and you're dealing with financial stability risk and perhaps a lack of resources. Too large, and as an expansion stage software company with a smaller project, you might not receive the right level of attention and get the best people on your project. I blogged on this in more detail here.
3. Sweet Spot Project. What's the vendor's sweet spot project? Similar to understanding methodology, force clarity on what the company's ideal project looks like in terms of team size, longevity, type of work (internal IT, testing, commercial release, ownership of full product, ownership of some component, etc.). Then make sure that your project is their sweet spot project (without telling them anything about your project). If not, look for another vendor. For example, you don't want to have a 6 person 2 year project with a vendor whose focus is on 50-person indefinite projects.
4. Domain Expertise. If your project is Java-based, you want a vendor with strong Java experience. If it involves understanding of data warehousing, you want someone who's been there, done that in building data warehousing applications. A vendor that builds internal IT applications for financial institutions is not a fit for you if you're looking for them to build a part of a commercial B2C application.
5. Maturity of Company. You generally want a company that has experience. A vendor that's been around for 10 years is likely to have had to overcome more challenges, learned more, and developed more professional approaches than someone around for 3 years. You also want to interview members of the senior management team. How mature and experienced are they? After all, these are the people who set the culture and the tone for the outsourced teams.
Next week, I'll focus on other issues, including experience with companies similar to yours, best practice and tool adoption, turn-over, access to best people, and price.
This week and next, I want to share 10 practical tips for choosing an offshore software developer (Jeremy and I are quite competitive), focusing on a few other items. Specifically, I focus here on outsourced vendors, and what questions to ask to increase the probability that you -- an expansion stage software company product development team -- end up with the right one for you.
1. Methodology. As you know, there are many different approaches to managing software projects and building software. From waterfall, to 20 different flavors of Agile product development, and everything in between, the methodology the team adopted can impact how it manages the project, how it communicates with its customer -- in this case you -- and how it actually builds the software. You want to understand what methodology the vendor is most comfortable with, and make sure it aligns with your needs, with your own methodology and that of your team. And don't ask, "What methodologies do you use?" or "Do you guys do Scrum?". A good sales guy will list everything under the sun in response to the first question, and answer yes to the second. Put them on the spot with: "I understand you do all that. But which one is the most prevalent in your company and your teams prefer?"
2. Company Size. What's the right vendor size for you? Too small, and you're dealing with financial stability risk and perhaps a lack of resources. Too large, and as an expansion stage software company with a smaller project, you might not receive the right level of attention and get the best people on your project. I blogged on this in more detail here.
3. Sweet Spot Project. What's the vendor's sweet spot project? Similar to understanding methodology, force clarity on what the company's ideal project looks like in terms of team size, longevity, type of work (internal IT, testing, commercial release, ownership of full product, ownership of some component, etc.). Then make sure that your project is their sweet spot project (without telling them anything about your project). If not, look for another vendor. For example, you don't want to have a 6 person 2 year project with a vendor whose focus is on 50-person indefinite projects.
4. Domain Expertise. If your project is Java-based, you want a vendor with strong Java experience. If it involves understanding of data warehousing, you want someone who's been there, done that in building data warehousing applications. A vendor that builds internal IT applications for financial institutions is not a fit for you if you're looking for them to build a part of a commercial B2C application.
5. Maturity of Company. You generally want a company that has experience. A vendor that's been around for 10 years is likely to have had to overcome more challenges, learned more, and developed more professional approaches than someone around for 3 years. You also want to interview members of the senior management team. How mature and experienced are they? After all, these are the people who set the culture and the tone for the outsourced teams.
Next week, I'll focus on other issues, including experience with companies similar to yours, best practice and tool adoption, turn-over, access to best people, and price.
To successfully adopt an Agile product development method, a developer team needs to work with product management to nail down the 'Definition of Done' of a software specification, or "User Story".
This is key to a successful product management process, especially at an expansion stage software company where other process definition and structure may be lacking and some fundamental definitions need to exist.
Definition of Done specifies a common understanding, agreed to by product management, development, and the senior management team, that says, "This software is built, and....".
The "...." can mean:
- Fully tested and ready to ship to customers
- Fully tested and ready to ship to beta customers
- Partially tested and ready for full QA cycle
- Code written but not tested
Having this definition gives teams clear goals and saves a lot of conversation about what got done and what didn't, and who committed to what, and so on.
Ultimately, it helps insure quality product and happy customers.
For an example of what happens when the Definition of Done is not clear or weak, consider the sink below.
I took this picture after the shiny new automatic/motion sensitive water faucet and soap dispenser were installed, making a significant (and probably expensive) upgrade to the rest room.
Of course, this also involved removing the manual soap dispensers.
While this upgrade was designed to make the rest room look nicer, more modern, and give a much better, sanitary experience to the building occupants, and 90% of the work to get there was done, the spots where the manual soap dispensers used to be were left unfinished, looking the way they do below.
Not very good customer experience. One way to avoid this would be to specify in each work order, "Do any clean-up, fixing, repainting, filling after installing the automatic..."
An easier way: Have a Definition of Done that states any work order is not done until all looks finished, with any holes filled and painted, etc.
Have a strong Definition of Done, and don't let this be your customer experience!
Last week, I wrote about the importance of expansion stage software companies building fault tolerance into their products.
The principle of fault tolerance can also be applied to people.
A fault tolerant individual is one who can: work toward a goal without specific instructions, make reasonable assumptions, resolve challenges, and reach out to help only when the individual clearly cannot resolve the challenge or answer the questions.
A fault INtolerant individual is one who needs extremely specific instructions to perform any task/initiative and gets tripped up by any open question, any new challenge, anything unforeseen.
When staffing any team, whether product management, product development, customer service, or sales and marketing, you can typically get away with individuals who are not fault tolerant in certain very specific junior roles. You may want them there because they can actually very good at following instructions and you don't want anything assumed or done out of process.
On the other hand, when staffing other roles, especially when recruiting senior management teams, you want highly fault tolerant individuals.
Certainly, when OpenView Venture Partners consider companies for venture capital investment, we look for fault tolerant management teams, fault tolerant products, and fault tolerant companies, because nothing goes as expected!
The principle of fault tolerance can also be applied to people.
A fault tolerant individual is one who can: work toward a goal without specific instructions, make reasonable assumptions, resolve challenges, and reach out to help only when the individual clearly cannot resolve the challenge or answer the questions.
A fault INtolerant individual is one who needs extremely specific instructions to perform any task/initiative and gets tripped up by any open question, any new challenge, anything unforeseen.
When staffing any team, whether product management, product development, customer service, or sales and marketing, you can typically get away with individuals who are not fault tolerant in certain very specific junior roles. You may want them there because they can actually very good at following instructions and you don't want anything assumed or done out of process.
On the other hand, when staffing other roles, especially when recruiting senior management teams, you want highly fault tolerant individuals.
Certainly, when OpenView Venture Partners consider companies for venture capital investment, we look for fault tolerant management teams, fault tolerant products, and fault tolerant companies, because nothing goes as expected!
One of the best ways for an expansion stage software company to reduce its customer support calls, save engineers time in solving customers' problems, and generally have happier customers is to build software for scenarios that is not meant for!
Now, I don't mean developing functionality for use cases that don't align with the product's vision.
I mean making the product fault tolerant.
Product managers should assume that the users of the product will do things with it that the product managers and developers never imagined the users would do. And then they should build the product based on that assumption.
For instance, say there is a configuration to your software that:
A lighter example is a pop-up confirmation message for critical functionality, like, "You are about to delete 500 records. Once the records are deleted, you will not be able to recover this. Are you sure you want to do this?"
Remember, Agile development methods are ultimately all about making the customer happy.
Typically, product management and development teams equate making customers happy with allowing them to do more stuff with the product.
It can also mean not allowing them to do certain things that are bad for them!
And saving a ton of resource on resolving preventable customer issues is pretty good for the overall product management process and your company's bottom line.
Now, I don't mean developing functionality for use cases that don't align with the product's vision.
I mean making the product fault tolerant.
Product managers should assume that the users of the product will do things with it that the product managers and developers never imagined the users would do. And then they should build the product based on that assumption.
For instance, say there is a configuration to your software that:
- Makes no sense, i.e. a user who knows what he/she is doing would never set that configuration to achieve a conceivable goal
- Will cause the product to work incorrectly or crash
A lighter example is a pop-up confirmation message for critical functionality, like, "You are about to delete 500 records. Once the records are deleted, you will not be able to recover this. Are you sure you want to do this?"
Remember, Agile development methods are ultimately all about making the customer happy.
Typically, product management and development teams equate making customers happy with allowing them to do more stuff with the product.
It can also mean not allowing them to do certain things that are bad for them!
And saving a ton of resource on resolving preventable customer issues is pretty good for the overall product management process and your company's bottom line.
All expansion stage software companies, and frankly all business in general, encounter problems as they grow. All business growth strategies encounter impediments. All teams make mistakes, all people make mistakes, economies tank, and so on.
One big difference between companies that quickly get to the next stage of development and those that get stuck is the way in which these problems / impediments / mistakes are handled by senior management teams and companies as a whole.
In encouraging Agile development methods adoption in the companies in our venture capital portfolio, one of the most important things we push for is the adoption of the retrospective and the surfacing and removal of impediments.
At the end of the day, as long as teams are reflecting on their days, weeks, sprints, months, and quarters, and are aggressively looking for and identifying impediments to doing better, and eliminating those impediments, chances are the teams will get better over time and will successfully navigate adverse changes.
Once the basic rhythm is in place, the next stage is to become very good at identifying the root cause of various impediments and really removing them, rather than identifying problems at a more superficial and obvious level and working to remove the problem without actually succeeding.
A company really starts to accelerate when these practices become part of the culture across all function areas.
This requires discipline, skills, and experience. Luckily, lots of people have written about this.
Ray Dalio, Founder and CEO of Bridgewater Associates, a $74 billion hedge fund calls it "getting at the truth", and refers to a basic process that has served him well in which diagnosing the root cause of a problem is distinct from identifying the problem and solving the problem (see his manifesto here, lots of great stuff for managers of any business).
There's asking the "5 Whys", described here, and Toyota's A3 sheet, here.
And much much more. It doesn't matter which approach is used or what it's called as long as a team is identifying problems, diagnosting the root cause, and removing it.
One big difference between companies that quickly get to the next stage of development and those that get stuck is the way in which these problems / impediments / mistakes are handled by senior management teams and companies as a whole.
In encouraging Agile development methods adoption in the companies in our venture capital portfolio, one of the most important things we push for is the adoption of the retrospective and the surfacing and removal of impediments.
At the end of the day, as long as teams are reflecting on their days, weeks, sprints, months, and quarters, and are aggressively looking for and identifying impediments to doing better, and eliminating those impediments, chances are the teams will get better over time and will successfully navigate adverse changes.
Once the basic rhythm is in place, the next stage is to become very good at identifying the root cause of various impediments and really removing them, rather than identifying problems at a more superficial and obvious level and working to remove the problem without actually succeeding.
A company really starts to accelerate when these practices become part of the culture across all function areas.
This requires discipline, skills, and experience. Luckily, lots of people have written about this.
Ray Dalio, Founder and CEO of Bridgewater Associates, a $74 billion hedge fund calls it "getting at the truth", and refers to a basic process that has served him well in which diagnosing the root cause of a problem is distinct from identifying the problem and solving the problem (see his manifesto here, lots of great stuff for managers of any business).
There's asking the "5 Whys", described here, and Toyota's A3 sheet, here.
And much much more. It doesn't matter which approach is used or what it's called as long as a team is identifying problems, diagnosting the root cause, and removing it.
I was discussing Agile development with a fantastic coach, Dave Hussman at DevJam , the other day.
Our conversation turned to the simple fact that if you focus all your attention on the act of building and delivering software and not on understanding if what you're building will make you tons of money, well, Agile will just make sure you go out of business more quickly than you would have on waterfall.
To me, this means Product Managers, Product Owners, and lots of market research, something I wrote about recently here.
The form of market research that Dave suggested to me is much simpler and, from what he tells me, is quite effective: If you're considering building a brand new product, or an add-on to an existing product, identify the keywords associated with it (what will you market on once you've built it?), set up a landing page, and buy the keywords. Then look at Google Analytics on the landing page and see what happens.
If you get lots of high quality traffic, that's probably a good sign you should build it.
If you're not getting much high quality traffic, that means you should probably change the keywords or reconsider building it.
This is especially ideally for expansion stage software companies, like the ones in our venture capital portfolio, since this method is fast and cheap.
I would recommend senior management teams apply this idea to their content marketing strategy as well, since creating great content can be resource intensive, and you may want to make sure there's high demand for it first before you create it.
Our conversation turned to the simple fact that if you focus all your attention on the act of building and delivering software and not on understanding if what you're building will make you tons of money, well, Agile will just make sure you go out of business more quickly than you would have on waterfall.
To me, this means Product Managers, Product Owners, and lots of market research, something I wrote about recently here.
The form of market research that Dave suggested to me is much simpler and, from what he tells me, is quite effective: If you're considering building a brand new product, or an add-on to an existing product, identify the keywords associated with it (what will you market on once you've built it?), set up a landing page, and buy the keywords. Then look at Google Analytics on the landing page and see what happens.
If you get lots of high quality traffic, that's probably a good sign you should build it.
If you're not getting much high quality traffic, that means you should probably change the keywords or reconsider building it.
This is especially ideally for expansion stage software companies, like the ones in our venture capital portfolio, since this method is fast and cheap.
I would recommend senior management teams apply this idea to their content marketing strategy as well, since creating great content can be resource intensive, and you may want to make sure there's high demand for it first before you create it.
I came across a fantastic article titled 'Five Symptoms of Mechanical Agile' last week, written by Daryl Kulak of Pillar Technology.
In it, he tells 5 stories of Agile teams going from performing well to performing terribly by trying to do "better" in response to external forces.
I recommend you read the whole thing.
At the end of the article, Daryl offers a few recommendations:
- If You See a Best Practice By the Side of the Road – Kill It
- Close the Gap Between Decision-Making and the Work
- Break Down the Boundaries Between Teams
- Value the Unstructured
- Avoid Over-Engineering Your Processes
What jumped out at me is that all the bad things that happened could have been avoided if the senior management teams in the situations had internalized one simple value from the Agile Manifesto: "Individuals and interactions over processes and tools"
As Daryl put it,
"These are the problems that keep your Agile teams from scaling up and sustaining. And they all relate back to treating people like machines instead of like people.
To solve the Mechanical Agile, no amount of new practices or Lean, Kanban or Six Sigma will help you. Scrum of Scrums won’t really help you. More meetings won’t help you. Only addressing the attitude of thinking of people as machines will help you."
It is this same wrong attitude that lies at the heard for the misuse of metrics, as I discuss in my post 'Metrics Gone Bad'.
In fact, to truly build a great company, you have to go one step further. Not only do you need to treat your people like people and not machines to be programmed and manipulated, but you need to treat them as assets.
After all, as someone very wise once wrote (I can't now remember exactly who), a good manager is only right 50% of the time, and knows it. His or her people, the assets, are right the other 50% of the time. Together they work to build a great business.
If the manager is arrogant, derives his or her expertise from lots of books, best practices, and management classes, and his or her power from manipulation and over use of process and metrics, that manager turns his or her people into what they're being treated as: machines, and not very valuable ones at that.
Now, I'm not saying don't read management books or don't utilize best practices. After all, one of the ways OpenView Venture Partners helps the expansion stage software companies in its venture capital portfolio is by doing just that.
What I am saying is: viewing your people as valuable assets comes first, the other stuff comes second. And when the other stuff goes against the first part, forget about it!
Powered by Compendium Blogware