how to do product software development?

Question

We don't have an agreement on how to go about this process.

The characteristics of what we are building:

1. There is already a market, and its already saturated. Meaning there is established competition.
2. We don't know how our competitors do it.
3. No two customers are the same. Its easy to define features. Its not easy in deciding how to implement them. [Point 2 is emphasized here again].

Given this plight of things, I am of the opinion that we sit together (may be for a day or two) and generate a matrix of common problems faced by the business (I think we call this business case), and jot down their solutions - i.e. the traditional business solution (with its pros and cons), our product's solution to the problem (with pros and cons). We can freeze on this by having it reviewed with stake holders.

Post this we can begin the task of creating user stories, wireframes, etc.

However, we actually go about building the user stories with a few business cases which on the whole fail to convince us on the acceptance of the system, or gives a false assumption of acceptance.

What is the actual way to go about it?

Answer 1

All such projects should start with a Business Case (BC). The BC should state the problem you want to solve or the opportunity you want to exploit. It should state the cost of undertaking the project (in resource and in hard cash terms) and the benefits that the business believes will arise from undertaking the project. In your case, since the nature of the product is not defined, I suggest a small preliminary project, with its own budget, to do some customer and product analysis to determine what the deliverable could look like and what features it needs to contain. The deliverable of the requirements analysis project should be the BC for the implementation project.

All BCs should be reviewed, approved and signed off by the business. They are your approval to proceed and allocation of budget to get the job done. Once you are there you are into straightforward project management. How you choose to deliver the project (and therefore the Product and other deliverables) depends on your local preferences (i.e. Agile/Waterfall/some other model)

Start by building a BC that stacks up (i.e. it brings more benefit to your company than the cost of completing the project- in simple terms, it brings in more money than it costs to build).

Then, and as part of the overall BC, nail down the features of the project and, if possible, separate them using MOSCOW, i.e. Must Have, Should Have, Could Have.

Get your budget. Run the project. Deliver the product. Make the money (or measure your benefits realisation)

Answer 2

From my experience in managing new product development, I think the first step should be to find a launching customer.

No launching customer = no reference case, no inside knowledge, IT-driven product, will hardly succeed in a satured market.

In your case I would recommend finding at least two launching customers that are willing to spend time and money, since the mix of requirements is too widely varying and you might up with a customer-specific solution otherwise. Alternatively, you might go for a person that has inside knowledge of the industry, having worked at potential customers, and has product management skills and is will to share.

The rest is just building a business case with MoSCoW, agile or whatever, but always the launching customers as partners aboard. Good luck!

Answer 3

Who is your Product Owner?

To me, it sounds like what you are struggling with is that you don't really have a product owner defined for this software. When doing software development, even if you're writing software that is market facing, someone has to represent the product ownership role as you develop your software. Otherwise, you're developing aimlessly, and ultimately have no way of knowing whether or not your code is providing value to anyone - including the people developing it. Product ownership is a critical aspect of software development - once you establish that, personally I would look into using some kind of agile development methodology so that you can more flexibly respond to the product owner's needs.

InfoQ has a good discussion of what a product owner is responsible for, here: Product Owner Patterns

One of the critical things to be sure of is that you have a prioritized product backlog. Without a product ownership role, there's no way to expect to have a backglog of things to work on that are important.

As a general resource for development practices, I'd also recommend this blog, written by the engineering staff at Etsy: Code as Craft