PowerPoint Karaoke (or table topics?) Wed, 2013.11.27Posted by Charles Rivet in blog, Funny, product-management, Video.
Tags: battledecks, Clubs, Microsoft PowerPoint, Organizations, PowerPoint Karaoke, ProductCamp, ProductCamp Ottawa, Self Improvement, Toastmaster, Toastmaster International, United States, youtube
add a comment
At the recent ProductCamp Ottawa, one of the submitted topic was PowerPoint Karaoke – something with which I was not familiar. The description seemed interesting, but there were other topics to attend. I actually don’t even remember whether it was one of the picked topics – or maybe it was running at the same time as mine – but that does not matter. I decided to look this up and found a good description (with tips) and this SXSW 2008 recording (they call it “BattleDecks” but it’s the same thing):
This seems like a lot of fun! Back when I was a member of a ToastMasters club, we had this thing called “table topics” where you were given a topic and then, without preparation, had to talk for 40-60 seconds about that topic. This is a similar idea, but with a set of PowerPoint slides! I used to enjoy table topics, I guess I would also enjoy this!
ProductCamp Ottawa – November 2, 2013 Mon, 2013.10.28Posted by Charles Rivet in Agile, conference, OPMA, product-management.
Tags: Canada, CaseWare, Ottawa, ProductCamp, ProductCamp Ottawa, unconference
If you have any interest in the various aspects of product management, you should consider registering and attending. There are currently 11 proposed sessions, including my own (session #9: Agility in Product Management).
No one is sure yet which session will be running as the participants will be voting for the selection as the first action of the day.
I look forward to meeting you there!
Tags: 3c, collaboration, communication, cooperation, organisation, silo
In the past, I’ve experienced a lot of cases where silos existed within companies and organisations. More recently, with my work with communications service providers, the silos between product management (part of the CMO organisation), business systems (BSS, part of the CIO organisation), and operations (OSS, part of the CTO organisation) illustrated the problems in delivering their products to customers.
More recently, I was reminded of this during last week’s meeting of the OPMA (Ottawa Product Management Association, which also includes program and project managers) and an INCOSE Canada (International Council for System Engineering) symposium. These silos certainly appear to be the norm in many organisations – and seldom to beneficial effect!
The problem with these silos is that they encourage the transfer of information through documents that are passed “over the wall”. Although this could be seen as a sign of collaboration (e.g., “I provided the requirements, my job is done!”), it is not truly conducive to all parts involved in the product delivery process understanding and meeting the needs of the stakeholder (“the customer”). It also does not promote the adoption of an agile approach, especially when the needs of the customer change or are better understood.
I have come to think of this problem as on of “3-Cs”: Communication, collaboration, and cooperation.
There has always been a lot of talk about communication being essential to everyone knowing what needs to be done. Unfortunately, the silos tend to make this communication one-way, and I do not see that as communication! Communication that just goes one way is publication, even publicity in some case (e.g., “See, I know what the customer wants!”). Publication also tends to be a point in time occurence and not continuous. What is needed is communication that is a continuous dialogue that occurs regularly until the product is delivered – not just at the start and end. Participants need to be able to ask questions and get answers in order to get to a common understanding of what needs to be done, of what the customer problem and needs are and and how they will be solved.
But communication is not enough. There also has to be collaboration during that dialogue – it can not only be a question and answer exchange. Participant need to provide insight from their own knowledge and experience. This collaboration will help the company achieve the best solution for the customer’s problem.
And even that is not enough – we also need cooperation. Collaboration has a tendency to only occur during specific communication events, e.g., meetings. Cooperation happens when communication and collaboration happens spontaneously. In many cases, it is the result of the synergy that happens when communication and collaboration become almost symbiotic, when the team knows enough about the whole product that, when new information becomes available, they are already thinking about new ideas to meet the customer’s needs and they already know who to talk to – there is no more need to way for the next meeting or to create a new document. At this point, the silos are broken and success is assured.
I do realise that I am taking some liberties with the formal definitions of my 3-Cs, and I make no apologies for that. It is an easier mnemonic to deal with (especially since it seems to have already been used often as such).
The important thing in all this, after all, is to remember that when developing products, we all need to become more agile and dedicated to meeting the customer’s needs and solving their problems. If we don’t, we will take longer and risk losing the customer!
Corporate mass & inertia prevents agility Fri, 2013.09.13Posted by Charles Rivet in blog, product-management, software-development, systems, systems-engineering.
Tags: agile, devops, product-management, SAFe, sailing, software-development
Tommy (someone for whom I have the greatest respect) made some very interesting comments in his posting: Corporate mass & inertia prevents agility.
Now, I have also had some experience sailing and that certainly helps me relate to the metaphor he uses. Sometimes I like the slow boat and sometimes the fast one – it really depends on what you want to accomplish. However, in this age where “internet time” is what companies have to worry about, agility is what is needed for the complete delivery of products. There has already been a lot of talk about agile development for quite a while – and that is certainly a great thing for the software industry, but development is just a part of the product delivery, one has to embrace the complete lifecycle and think about agile product management (check out the front end of SAFe) and agile DevOps.
But then, there’s also some benefits to sometimes take a slow boat to China…just not when you need to deliver a product to your clients!
Your Business May Depend on Your CMO and CIO Working Together Tue, 2012.09.11Posted by Charles Rivet in article, governance, ibm, innovation, jazz, organisation, product-management, rational, software, software-development, systems, systems-engineering, telecom, tools, work.
This is a great article that brings up some issues that can prevent the CMO and CIO from working effectively together and aligning their decisions with the enterprise’s business objectives, instead of their own departments.
This is also an area where IBM Rational can help, in facilitating collaboration between these two, sometimes silo’ed, entities, especially where software and system intensive solutions are at play.
IBM Rational’s tools for product portfolio management can help manage the input from both the CMO and CIO teams to the definition of the products provided by the enterprise. Each division provides its needs, its objectives, and its desired outcomes, and IBM Rational Focal Point can help blend all of this and keep it aligned with the overall division and enterprise business objectives. Each product (or project) can then be evaluated against these business objectives and scheduled accordingly.
Further integration between the product portfolio tools and IBM Rational’s collaborative lifecycle management platform then ensures that the software and system requirements can be traced to the implementation and deployment of the software/systems products.
Yes, this is a simplified view of the whole thing, but it can and has been done in the past!
What to do with “legacy” products? Wed, 2009.07.15Posted by Charles Rivet in ibm, product-management.
Tags: legacy, product-management, products
I am now in charge of the product management for a bunch of “legacy” products. You know, those products that are old and, some cases, decrepit, but that our customers just love to keep around. They are comfortable like a well-work pair of jeans or broken-in shoes. But these products are based on old technology and we now have new platforms, enhanced capabilities, new UIs, etc. that should entice our clients to move…but some of them are stubborn.
So what do we do with these products that still bring in revenue (mostly maintenance, but some transactional)? They bring too much revenue for us to simply decide to throw that away (especially in this time of economic upheaval) as we fear those stalwart clients will move to the competition. And our new offerings, although more powerful, are scary in just those additional capabilities!
There are a few things that we have to look at for those products.
- First, to borrow from the medical profession, do no harm. This means that our current clients must feel they are not in a dead end – even though the product itself will not be updated. These users like the product as it is, so we need to work with them to determine why it is still the best tool for them. We need to see if this is a niche that we need (want) to address with an offering, perhaps a modified version of an existing, high capability offering.
- Second, we need to get these clients to move to something that we will want to support and augment in the future. We need to make this transition as painless as possible both from tool migration and from usage perspectives. Note that I states “as painless as possible” as it is often difficult to make this painless. Sometimes the artifacts do not migrate properly between the tools and require manual changes, sometimes the user experience is different. In either case, there will be some pain. From a tool perspective, the goal is to make sure that not information/data is lost in migrating the artifacts and to document the migration caveats. From a usage perspective, we need to document the changes in the way the tools look and in the way standard or common tasks are accomplished. This is where the user-centric design teams are very important. In all cases, we would want to consider services to help these clients including consulting, training, and pre/post-sales support.
- Third, we need to arrange the two previous points so that our development, maintenance, and support costs are minimised. These are legacy products and are typically not expected to be a drain on resources. We also want to be able to move the resources from these products to our strategic offerings (which should be the migration targets!). Although this is not directly related to our clients, we can’t expect them to stay on the old, comfortable applications forever and, at some point, all these resources will have to move.
So how does this translate into actual plans and activities? This is where knowledge of your products and clients comes into play – and this is what I have to figure out for my products! I don’t yet have an answer, especially not a generic one. But I may just come back to this blog to let everyone know…
IBM knows what to do with Telelogic Mon, 2009.01.12Posted by Charles Rivet in blog, ibm, product-management, software-development, telelogic.
This SD Times article is a bit old, but yes, we know where we are going with the Telelogic tools. You could say that it has been an interesting process (along the line of the curse)!
Contact your account team if you want to know more as I can’t talk about futures here…
Systems are go! Thu, 2007.12.13Posted by Charles Rivet in ibm, product-management, rational, software, systems, Uncategorized, work.
If there was any doubt about IBM Rational re-insertion in the systems space after the announcement that we intend to acquire Telelogic, these should be put to rest with the announcement made yesterday that New IBM Technologies Help Developers Build Safer Software!
So what is new in RSD 7.0.5? Here’s a quick list:
- Improved rectilinear routing
- Configurable Modeling UI
- Viewpoints let you reduce the UI to only what you need
- Rich text support for documentation, notes and comments
- Modeling Reminders
- “TODOs” for incomplete models
- Diagram building using drag & drop queries
- UML 2.1 support improvements
- Support Information Flow elements (UPDM requirement)
- Deployment Diagram enhancements
- Sequence diagram editing enhancements
- Message and message subset reordering
- Resizable lifelines
- Enable/disable message numbering
- Choose message numbering format
- BIRT-based model reporting
- Model analysis and metrics
- C++ support enhancements – CDT 4.0
Of course, you also need a testing tool in this space and that’s Rational Test RealTime, which is also mentioned in the article. If you do embedded systems development, you should not have to live without it!
Powered by ScribeFire.
IBM Rational Systems Development – live on external site! Fri, 2007.01.19Posted by Charles Rivet in ibm, product-management, systems.
IBM Rational’s Industrial Systems Solutions we now have a renewed and rejuvenated presence on the external IBM web site!
If you want to see what Rational is doing in this space, I would invite you to go see!
And yes, in the interest of disclosure, I am a product manager for this space…