Starting from Scratch? Lessons Learned From Trying to Create Software as a Service at SAP

“Starting from Scratch? Lessons Learned From Trying to Create Software as a Service at SAP” with Mike Tschudy, VP, Product Design Group, On Demand Applications at SAP

By Tej Ravindra

February 2012 Event

In February’s SVPMA monthly meeting, Mike Tschudy shared his experience and insights on developing SAAS solutions from a scratch. Three key takeaways were: a design thinking based approach to new product development, quick prototyping and team development for customer focused solutions.

DESIGN THINKING APPROACH TO PRODUCT MANAGEMENT:

The focus of this talk was the new product development process that was used to develop the SAAS solutions at SAP.  Mike emphasized 4 principles of this process:

1. Empathy for people

2. Interdisciplinary teams

3. Shared Vision

4. Iterative build cycles

This methodology is people and team centric. Team building is the most important thing.  An example: At the start of the project, invest time in getting everyone on the team to share some background on their interests and experiences.  You learn all sorts of things. There are a lot of people hiding behind their roles and have passion and excitement.  Often teams are in a hurry to execute. Different teams are measured on competing priorities and the end result can often be a product that may only be marginally successful although each specialized team met their specific goals.

Customer centricity and constantly gathering feedback on your prototypes helps the product evolve fast and in the relevant direction.  Connect with the people you build products for. Engineers have to be part of the conversation right from the beginning. Get engineers and designers engaged on the customer problem you are trying to solve from day 1.

Example: The team members built out scenarios and went through real data. Engineers, product managers & designers story boarded out their product requirement documents. Customer stories, backlog definitions and storyboarding were used to define what was being solved. Having visual cues on what’s being solved help people get on the same page really fast. Turned out that this scenario was not right for SAAS and the team was able to move in a different direction.

Prototyping and building up front without too many months of time investment. Organizational design is a key factor in facilitating this. Service organizations with specialized departments for each functional area are not best set up to do this. The product team needs to own the resources and the function to stay agile. Every person on the team needs an understanding of the customer’s context and pain points.

For SAP, a company that was focused on enterprise solutions,  building a SAAS solution was a fundamental change in the product context, the customer they were building for and the speed at which they could execute. This paradigm shift for new product development demands an agile and design based product management approach.

Lessons Learned:

  • No employees, only true believers: Clearly state what the product values are and how they will influence decisions. People with full buy-in need to be handpicked.
  • Start small… Keep the team size minimal. Work on specific products or cross-topics with dedicated teams of ten (max. 2)
  • Team is everything… Break the role SLA and get people to share their talents and competencies openly, then decide on role responsibilities
  • Buy in… Clearly line out our approach at the beginning of a project and get buy in from the stakeholders. No shortcuts!
  • Common MBOs… Everyone needs to know what they are working for. Its bureaucratic but it makes a difference
  • Get out of the building and validate… This builds confidence and reduces ambiguity

Tej Ravindra is a Sr. Product Manager at eBay. In her previous roles, she has led product management for SAAS and B2B software. Her interest areas include technology & business strategy, mobile applications & data analysis to drive better business decisions.