Often BD misunderstandings in SaaS industry

SaaS industry more than any other creates contrasts. It's mostly because it combines very strict technology world with funky spirit and humanistic aspects of sales. Unfortunately often that contrast creates misunderstanding and wrong assumptions. If we think about engineers, a lot depends on character and experience. When it comes to business most of trouble is misinterpretation of common terms that sounds much better than they look like. Let's discuss briefly most misunderstood terms.

About me: I am over 13 years in IT industry. I started as a home-grown developer, evolved to a senior engineer, architect, manager and startup team assembler. I try to combine economical education and knowledge collected over the years to help entrepreneurs reach their goals. My observations are based on experience of myself, my colleagues and business partners. Many non-IT learnings are lessons given by my mentors, bosses and investors basing on their own failures, successes and learnings. Every project I join benefits from it and I hope you can benefit too.

MVP – Minimum Valuable Product

1. MVP in SaaS often is one single goal/problem achieved/solved by using a service
2. CEOs often understands MVP as a minimum shape of the product which in their opinion will satisfy customers and defeat competition

What is being lost:

• assumption is worth nothing, validation by users and measurement is a key
• something that people say/we think is good enough can take months/years to achieve and direction can be wrong
• worth reading http://steveblank.com/2010/03/04/perfection-by-subtraction-the-minimum-feature-set/

Agile/Rapid Development

1. Agile is a methodology that tries to limit weakness of a waterfall. It focuses on continuous validation of priorities.
2. Many business people understands it as ad-hoc, for yesterday, do it now development
3. Many managers leaves no space/time and often pushes out analytical mechanism from Agile, that turns process into chaos
4. People in general want all at once
5. Sales people creates dates combined with result, and then announces that to engineers

What is being lost:

• Agile requires all team to use it, not only engineers proper Agile focuses on small goals, most businesses focus on big goals
• Agile secured product creation processes from all at once pressure. Business departments hardly ever keeps to that hermetics and pushes things in middle of the sprint
• Agile requires tools like testing, estimating, measuring, retrospective; Business calculations keeps them as luxury in the future
• Agile works out estimation, that in time gives the idea about delivery times; Managers very often make delivery times and expects it happen
• last but not least: Agile makes team define and creates product knowing raw goals of Product Owner; Product owners often creates detailed requirements, often not leaving space for their validation and internal errors detection
• ... and Sales often sells not existing product, but defined, then gives it to Agile

Processes

1. Process is something that lasts, but also often requires also some period to warm up
2. Sale oriented people usually assumes once process is agreed, result is in its place

What is being lost:

• Process of estimation by the team who don't know the product or is freshly formed requires at least a few months to start being valid
• Processes have dependencies. In more complex (often most of) systems proper development requires process of planning, which requires process of designing (including architecture), which requires process of R&D
• Many processes are being ignored and forgotten, or worse it's assumed that they will happen next to 100% occupying activities like production. For instance: security audits, infrastructure planning and deploying, process deploying, testing, retrospective, analytics, R&D

Prototyping

1. Prototype is basically working proof of concept. It's usually made low cost with ready tools.
2. Many unexperienced people assumes prototype will handle huge loads and match all expectation.

What is being lost:

• Of course many businesses need in reality Magneto or Wordpress. Rest of them just proper manual service and content. But when we talk about SaaS we expect often bigger complexity and loads, which many out of the box solutions not give.
• Prototype is focused on user validation. That something works for user, don't mean it will handle hundreds of them at once.
• Prototype is based on assumption. You need to measure how it works, then plan work basing on results.
• Prototype hardly focuses on security and reliability, because you want it FAST.

Delegation

1. Delegation assumes that superior moves part of responsibility to other people/departments

What is being lost:

• with responsibility you need to deliver tools and power (otherwise it's just cruel)
• if you delegate you have to trust
• if you delegate it may happen that decisions will be different than your own. Or you can choose people who think like you, or better, you can choose people who has more expertise and will make better decisions
• if you delegate you have to precise, adding blurred or shared areas will create conflicts

Sale Character

1. Business people have often sales experience, they are trained to negotiate, underline advantages and ignore downsides

Where is the issue:

• It's good to seek for alternatives and short wins, anyhow engineering is not a sale. There is a fair unbreakable relation between quality, price and time (see http://en.wikipedia.org/wiki/Project_management_triangle)

Of course there are plenty more. To be fair often misunderstanding happens on the other side. For instance engineers forget about assessing tools to needs and like to choose cannons to shoot mosquitos. But that is the reason to find a proper CTO (read here).

Hope those notes will help. If you need help to discuss strategies in you SaaS company, feel free to ask.