The project to product movement is quickly gathering speed - a recent Gartner report found that 85% of respondents are shifting to a product-centric mentality. However, the complexity and uncertainty of software delivery at scale, coupled with the sheer number of people involved in the process, is too much for traditional project management techniques. Motivation is not enough to achieve a successful transformation—the product-centric model requires new skill sets, different investments and a change in culture.
What does the shift away from project-thinking really look like?
During this webinar, Tasktop VP of Product Development, Nicole Bryan, combines our own journey with the experience of working with our enterprise customers, to paint a clear picture of the cross-organizational challenges in store - and how you can address them by:
- Adopting a “customer-first” mindset
- Appointing a Product Value Stream Lead and a Product Manager
- Implementing the Flow Framework™ to align the language of IT with the language of the business
Moving from Project to Product: Oh My - Does it Really Involve That?
The Project to Product movement is clearly afoot. But what is it really like to move to a 100% product value stream based organization? In this talk, Nicole will provide the good, the bad and the “oh my I had no idea that would be a thing” of moving from an agile and devops structured organization with engineering and product separate teams to a single combined product development team organized solely around product value streams. Tasktop is one year into their journey of this effort and will detail experiences ranging from how it affects HR (who knew … you’ll have to redo all of your career ladders!), finance (you want me to breakdown revenues by what?), marketing & sales (why are you talking about these foreign “tech debt” things - they are not features for my customers), executive management (what is the actual business value I’m getting for doing this?) and of course product development itself (But my product is really a service to other products - is it still a product? Also, we are already so so agile - do we really need this?). Come learn from the victories and pitfalls so that your journey from project to product can be as effective and smooth as possible.
Moving to Product Value Streams Talk
What were the primary goals
Relentless focus on customers and *business perspective* - that is what drives a business
Marry that to the internal realities of how we actually deliver
Can I talk about Viz at all? (Just from the perspective of new product development?)
Show the org chart before - the final decision roles up to the CEO - what your goal is is to have the final decisions role down as much as possible
Day to day work of engineers has not changed
Lucas view of being a PVS Lead vs. Jeff view given their backgrounds
Role of PVS lead vs product manager
Dependencies between PVSs is *not a bad thing* — you need to carefully consider the implications
What is a PVS lead vs. a product manager
Did it mostly affect the top?
If you are a coder, is anything really different?
Engineers were very clear about what an engineering manager did (theoretically)
But it really just made people think less about the customer
The simple fact of reporting to a PVS Lead vs. a VP of Engineering sends a different message - it might be subtle but it matters
Whatever problems were there before don’t just go away ;) - in fact, they become bigger
What hasn’t worked
Put in sabinas quote about people don’t fear change they fear loss
Not change management but rather
Loss management combined with opportunity maximization
irony that product people felt more lost - felt more swallowed by the bigger size; new layer was put in between which is never popular
NPS after change happened?
Opens Pandora’s box ... so long standing issues all the sudden come out that really had nothing to do with the org change
“Most engineering teams are either fixated on code quality or implementation speed, while most designers focus on the aesthetics. On the other hand, product teams mostly concentrate on delivering projects on time and on budget.” https://www.codementor.io/blog/how-to-be-the-engineering-manager-your-company-needs-1yahjbf97x
Last year, I stood I believe on this same exact stage as VP Product Management – and the reason I’m here today is really to talk about why now my title is Product Development, not Product Management.
Oh my has really sort of become my mantra during this … why? Because I think it evokes a sense of thoughtfulness and empathy while at the same time not being judgmental in its intention and interpretation. So… “Oh My” is your friend as you embark on this.
So I get that most of you might be thinking “what does she know” … but before you discount I actually believe that because of our smaller size we were able to “see into” all of the effects and impacts more readily- so I can talk to Finance, HR, Marketing/Sales, Business Development easily because of our size and get insights into the holistic effects of moving to product value stream. So I really think a big company can learn quicker because of our experience … now of course, not everything would be the same, I get that but I feel confident that our experience can benefit large enterprises trying to embark on the move from project to product.
Project to Product movement is clearly afoot --
According to Gartner Survey of IT and IT-business professionals in Oct 2018: “Eighty-five percent of participating respondents state that their organization has adopted, or plans to adopt, a product-centric model. Fifteen percent have fully adopted one already, 39% expect they will fully adopt one for all work in coming years, and 32% expect to continue using project-based approaches for some work.”
The 2019 Gartner CIO Survey reported that 55% of IT organizations are moving from project to product management.
So is that why we are all here? Sure there is a macro movement afoot. But at Tasktop it wasn’t really about following the movement.
For us … it was about being flummoxed. And, yes, I’ve basically always wanted to be able to use that word in a talk so now I have – I can tick that box off the list.
Tasktop is a software product company? We aren’t a bank, we aren’t a retail company – so weren’t we already operating as a product oriented “product” company? We thought so.
But we had issues.
So as I said .. “We had issues” – but what were they – because on the surface we were ticking most of the boxes ….
So as I said .. “We had issues” – but what were they – because on the surface we were ticking most of the boxes ….
Context and Structure Matter
Distance from customer
”Refresher” on how to be customer first
The context and structure within which you work and the details around you matter
The further you are (or you feel) from the customer, the less you are running as a product-centric mindset
We needed a reminder, a refresher if you will on “customer first” … product thinking is only there was the mechanism for “customer first”
product thinking is only there was the mechanism for “customer first”
So we had these symptoms… and we began to see that we weren’t thinking “customer first” as much as we should;
That our mindset wasn’t quite right -
So we went back and re-looked at how we were approaching all of these aspects of product orientation … through the lens of “Customer First”
And we discovered something very interesting ….
The way we were thinking of teams (which, btw, is extremely common for software companies) was not “customer first” – and that inward focus affects the outward result
For us, we realized that at the heart of our refreshed sense of “product”, we had to reorganize to reinforce the values that ”product thinking” embodies – customer first
So that is what happened … that is what we “did”. But now I’m going to shift and talk about ”what happened because of what happened”
So that is what happened … that is what we “did”. But now I’m going to shift and talk about ”what happened because of what happened”
So we did what any good management team would do – we googled what to do ;). So we knew we were on our own in figuring this out…
So we did what any good management team would do – we googled what to do ;). So we knew we were on our own in figuring this out…
Prioritization, prioritization, prioritization
Generally no people management duties
Feature Design
Primary Flow Metric
Flow Time
Flow Load
Flow Velocity
That is of course a very tricky question …. And of course there is not a single answer to that
Tricky where to put connectors – shared component so decided to split out – but slightly less “customer facing” – so should we?
Treat your delivery pipeline like a product – so we do …. It is its own PVS – but you have to be careful with that too. If you don’t make it clear that your delivery pipeline is *not* responsible for running things for your teams you can get into trouble. -- and we have. So now we have essentially a delivery pipeline PVS (internal focused) but we embed those team members on other PVSs to help advise them and help them see where the lines are of who should be doing what.
Treat your delivery pipeline like a product – so we do …. It is its own PVS – but you have to be careful with that too. If you don’t make it clear that your delivery pipeline is *not* responsible for running things for your teams you can get into trouble. -- and we have. So now we have essentially a delivery pipeline PVS (internal focused) but we embed those team members on other PVSs to help advise them and help them see where the lines are of who should be doing what.
Advice on how to structure: Get the value streams as close to how *your customer* would intuitively delineate … and then layer in the practical realities on top of that
E.g. size of teams; shared components won’t necessarily be understood from the customer perspective
Be careful to have “the customer perspective” rather than ”the technical perspective”
There absolutely will be teams within PVSs
* However you structure the internal shared stuff – make sure teams don’t feel that they can’t contribute to that shared service
Who is in the role matters
If you have one leader of Product Development, should they come from the “engineering side” or the “product side”?
Biggest thing is that whichever “side” you come from you need to make sure to pay attention to “other sides” day to day lives – so things like concentrating on how we are doing QA ; not just customer feature prioritization
Day to day engineers said “my job hasn’t changed” … but I would argue that it has changed in the sense of the context in which they are coding
Investors need and want an income statement to be categorized by the traditional categories. For example, license revenue, maintenance revenue, service revenue and cost of sales, sales & marketing expense, research & development expense, and general & administration expense. This allows investors to compare companies against each other and measure traditional metrics like how much is this Company investing in their future (R&D) versus this other company? Moving to a value stream reporting structure would be unique to a company since those products are unique to that company. Comparing how much costs we’re incurring for Tasktop Hub versus Sync isn’t useful for an investor who is trying to determine how much it costs us to gain a new customer versus how much it costs another company to gain a new customer.
There are also laws in place that requires us and every other company to report in this traditional way. Domestic tax authorities require us do so, so they can determine what’s deductible and not. Internal tax authorities requires us to do so, so they can determine if our transfer pricing policies unreasonably allocate profits to the lowest tax jurisdictions. Financial reporting authorities requires us do so, so they can determine whether our financial statements are materially misstated under GAAP. Therefore, any additional reporting is a “nice to have”.
Our investors’ needs and the laws determine our reporting structure. Our reporting structure affects everything that we do from the structure of the chart of accounts, the categories and dimensions available on our billing, purchasing and payroll systems, how we allocate resources for the upcoming year, how we measure against our budget, amongst many other factors.
Since we cannot rid of the traditional reporting categories, implementing a value stream reporting structure requires us to add a second reporting dimension to all the transactions flowing in and out of the company. Any seasoned finance person can tell you how complex this can get. Your chart of accounts could double. Your accounting system may need to be replaced. Your excel budgets will double in tabs. Just educating people on how to enter their time into the timesheet system may be a challenge. An engineer now has to determine if her time is R&D or bug fixes and whether it was Hub or Sync. A requestor now has to determine if a purchase order request is for office supplies or conferences and whether it is Hub or Sync. Some accounting systems let you add a “dimension” field that produces nice P&L statements by different dimensions. This is great if you have only one company, but what happens if you have multiple entities? How do you consolidate by value stream if your chart of accounts isn’t restructured? For historical revenue measurements, how do you classify by value stream if you never had the proper fields set up in you revenue module?
In the last year we’ve had to come up with “best class proxies” to estimate our lifetime historical results by value streams. Without getting too much into the hairy details, we’ve used a lot allocations based on where employees spent the majority of their time in a given period and we’ve used bookings instead of GAAP revenue to measure value stream inflows (this was not easy either since our Salesforce instance was not sophisticated in our early start-up days). The numbers aren’t 100% accurate when using proxies. But we hope to gradually modify our finance & accounting infrastructure to improve accuracy in the coming years.
As we continue on our journey, I’m hopeful that we’ll have a sophisticated value stream reporting infrastructure in the near future. Wish you all the best in your journey.
The first step in all of this is mapping out the current tool stacks and work flows. www.tasktop.com/value-stream-architecture-consulting
Here is what we don’t know what to do?
Here is what we would like help with