How to setup an agile startup without the customer? [duplicate]

Question

In agile, there is an emphasis on customer involvement. They provide user stories, provide feedback, and a lot of decisions are up to them.

There are situations that there is no customer for the software at the time of development. If we are going to ship a game -a software that people will be its customers after shipment- or if we are going to create a new service -like a new social network- and we are going to own it, there won't be any client present at the time of development.

I have a few questions for these environments:

1. Is there any software development methodology/framework specially designed for such cases?
2. Is agile applicable to such environments? If yes, How?

Update: It would be much interesting to know about a similar project developed agile.

Answer 1

You need someone to be a proxy for the customer. Someone in the team who takes on the role of Product Owner, or whatever it is called in your methodology of choice, and puts themselves in the position of a potential customer.

Note that this is a difficult job! But choosing the right thing to build is one of the difficult problems any start-up must face!

Answer 2

... who will the future client be? If you can't answer that, you probably have more significant problems than "how to run agile" since you are adopting a, "if we make something cool, people will buy it!" perspective.

You can do a variety of techniques to create an identity for this client. Perhaps a user persona acted out by your team members.

Having a documented "this is a sample user, here are needs of this user" makes it a lot easier to act this out correctly as well.

Answer 3

There are many possibilities open for you for situations such as this.

For the scrums meetings and day to day, as others mentioned, you should appoint a member of your team, typically the one with a more "visionnary" feel for your game, to act as the stakeholder. Do make sure that the person that is signing the checks is also represented, at least for your sprint reviews and sprint planning.

Next you should definitively get a broader feedback, play tests for example would be a great source of information. Usability testing is also good, they do overlap but both target different parts of your system (first checks if it's fun, the other checks how easy it is to get into it).

Stakeholders are an important part of the scrum methodology and should not be overlooked. They are in big part what keeps the dreams and wishes of the team firmly grounded with their perspective. So if you decide to play the role internally do make the extra effort to get external feedback as often as possible.

Answer 4

You may already know about this but you want to look at the books/ movements "Lean Startup" by Eric Ries and "Running Lean by Ash Maurya.

Both cover concepts and methods of determining with incremental design, prototyping and development, discovering who your customers might be, what your product needs to be and where it needs to go, and in general, continuously testing your premises for even wanting to develop your product. They help you ensure that you don't spend a ton of money up-front in building stuff that no one might want.

Once you start actually building the product, techniques such as Scrum and Kanban can help you build incrementally/ continually - and prioritize what you should build by focusing on risk/ cost of delay and other factors.

This is a very basic response to your question - but one needs to better understand your situation for that. And if you haven't read those two books, you MUST!

HTH

Answer 5

Replace the word "customer" with "stakeholder". For a contract-software development gig, the primary stakeholder is the customer footing the bill.

For a speculative software or a game, the primary stakeholders are the owners of the company, or whoever else is putting the up front investment to make this happen. The stakeholder in that case often times has plenty of stuff to do other than programming, but needs to be kept up to date and involved with the development process. That person is responsible for imagining what the customer is going to want, or is responsible for selecting someone else to fulfill that role and serve as the stakeholder.

Then, read this: Five Worlds

Answer 6

I would say you should put yourself in the shoes of your customers. Try to do a SWOT analysis to figure out why would you buy such a software and decide on the potential requirements that a customer would request. From there you can I would recommend reading Business Model Generation written by Alex Osterwalder. I think this is a question that relates more of a how to build a software that is desirable.

Answer 7

Often Agile seems geared towards B2B interactions, where your "customer" is another company with a few representatives who are there to tell your group what they want. From what I understand, you are talking about the situation where you are making a product for mass distribution. In such cases, your customers are millions of people you hope want to use your product. You don't really have anyone to invite to your review.

The way we handle this is with a separate position, a "Product Manager", who is in essence responsible for acting as the customer. They will analyze the market, do competitive analysis, survey customers, do user testing, and anything else to try to understand the target customers. That person acts as your customer. They end up working closely with the product owner in that regard.

If you are small, and can't have a separate product manager, the product owner can often double-up on that role. Though it is generally better to have someone separate, as the product owner also has to manage technical stakeholders.