Open Stack

I think one of the most important things we bring to the table is the melding of the technologies and the needs of the customers.  Developers have all sorts of great ideas for adding features and improving the existing ones, but they don't know how many customers need or want that particular feature or improvement.  We can provide prioritization of specs and blueprints based on customer demand, along with creating specs at a high level to address what the customers' biggest pain points or short horizon issues are.

We can also look at the velocity of development and project possible roadmaps for getting features and improvements in, beyond the single cycle, or single cycle plus fudge.

We can also provide an ecosystem view of the the current release and maybe even roadmaps, so everyone knows what is planned to be delivered by the OpenStack organization in the next release, and even better, highlight cross project dependencies that can be tracked to raise flags when one of the critical path items gets bogged down.

I think our greatest strength is being able to view the ecosystem from a high level and dig into the details enough to point out where the individual components need development focus.

--Rocky

-----Original Message-----
From: Roland Chan [mailto:roland at aptira.com] 
Sent: Wednesday, December 10, 2014 3:29 AM
To: product-wg at lists.openstack.org
Subject: Re: [Product] An "Operations Project" and the questions it raises.

I think we produce guidance on how to make stuff better or influence how
stuff is improved.

Ultimately what matters most is customer satisfaction. We can't frame that
purely in terms of feature delivery rates although getting the right
features to the customer is very important. Features have to be delivered
to a prioritised schedule, but also they have to work as advertised, they
can't break other stuff and they have to be deployable.

Probably more stuff too, so feel free to add to the list, but try to remain
at a high level otherwise we'll get lost in the solution before we've
finished requirements.

Roland
 On 10 Dec 2014 12:50, "Stefano Maffulli" <stefano at openstack.org> wrote:

> On 12/07/2014 11:38 PM, Roland Chan wrote:
> > Stefano's points on coordination and prioritisation are the tactical part
> > of product management. It's the strategic part that concerns me: what are
> > we going to do to improve OpenStack as a product (which is a lot more
> than
> > shipping the latest release) in a changing environment?
>
> I always thought of this group as a tactics-focused one since the
> strategy for OpenStack is done at TC and Board level but re-reading your
> message though I think I can be convinced of the contrary: what do other
> people think?
>
> > I would go with something like:
> >
> > The Product working group is made of managers, people, functions, groups
> > that own "products" based on OpenStack who aim to improve the quality of
> > the delivery process, the delivered product, and the product experience
> for
> > operators and end users. We do this by coordinating our actions,
> advocating
> > on behalf of our customers for improvements in all areas of the OpenStack
> > community's activity and continuously measuring our progress.
>
> Sounds better than the one we have. Do others want to chime in and iterate?
>
> > What we measure is an interesting question.
>
> How about we start talking about what we produce and go from there? Are
> we going to produce something like a list of what this groups considers
> top priority blueprints/specs? Something else?
>
> /stef
>
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>
_______________________________________________
Product-wg mailing list
Product-wg at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg