Skip to main content

One version overall vs. one version per client

Last post 07:32 am June 3, 2014 by Anonymous
6 replies
Anonymous
01:59 am June 2, 2014

We're currently building a cloud based solution for our customers. We get many requests from our customers and based on these wishes we create and continuously prioritise our backlog.
During the sprint we work on these wishes and have a steady monthly release of our product.

Is it better to have 1 product version for everyone or where each client has its own version?

Currently how we work is that we implement and release an high prioritised item which was initially requested by customer x. Once this is released ALL of our customers gets this feature because we keep the version consistent.


03:44 am June 2, 2014

I think it is hard to answer this without profound knowledge of your business.
Are you the product owner of the product?
What may help you is the concept of "persona". This means, you create profiles for the different kinds of customers for which you develop the product. If you find that their needs are so different that they actually need different products, you may want to create several products. This means you also need several product backlogs and several development teams.
As long as you find enough common needs for the customers, you will want to keep it simple with only one product.
In this case your goal should be that each client wants to have the newest version. You can reach this by delivering value for them each month and avoiding a big bang. So if we are talking about one product, it is generally better to have one product version for everyone to reduce complexity.


07:30 am June 2, 2014

> Currently how we work is that we implement and release an high
> prioritised item which was initially requested by customer x. Once
> this is released ALL of our customers gets this feature because
> we keep the version consistent.

That can be a good model. Remember that a release isn't just a product for achieving revenue. It is also an experiment, a platform for validated learning. It is reasonable to target a release at a select few to begin with in order to validate a hypothesis, such as the viability of a proposed feature, before deciding whether to incorporate the change into the main value proposition. Alternatively, it can lead to a new MVP that serves a distinct market segment.


Anonymous
01:36 am June 3, 2014

I can imagine that "a version for all" can eventually led to customers getting functionalities which they didn't ask for in the beginning.
At my previous company we had the same issue which resulted in dirty hack in the code so that x clients could be excluded etc.


02:39 am June 3, 2014

Hi P. Ross

That is the case for most software, i.e. for a new release you won't use all new features. I am also guessing that keeping multiple versions will also require more testing, configuration, management compared to a single version. We had a similar approach some years ago where a major client had a specifik version. Although it was the same codebase you had to consider what version that the end user was running and adjust for that with feature flags etc.


03:17 am June 3, 2014


Posted By P.Ross on 03 Jun 2014 01:36 AM
I can imagine that "a version for all" can eventually led to customers getting functionalities which they didn't ask for in the beginning.



My smartphone also has functionalities which I didn't ask for in the beginning. However I'm still satisfied, because I'm not forced to use them. And many of them I even like meanwhile :)


Anonymous
07:32 am June 3, 2014

haha point taken guys...


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.