Project To Product: How we transitioned to product-aligned value streams
•Download as PPTX, PDF•
5 likes•1,216 views
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
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Project To Product: How we transitioned to product-aligned value streams
Similar to Project To Product: How we transitioned to product-aligned value streams (20)
More from Tasktop
More from Tasktop (20)
Recently uploaded
Recently uploaded (20)
Project To Product: How we transitioned to product-aligned value streams
- 1. © 2019 Tasktop AN EXPERIENCE REPORT: Transitioning From Project To Product
- 2. © 2019 Tasktop How we transitioned to product-aligned value streams Nicole Bryan @nicolebryan Vice President, Product Development @ Tasktop Technologies Nicole is the leader of our Product Development organization and has extensive experience in software and product development, focused primarily on bringing data visualization and human considerations to the forefront of DevOps and Agile. Project To Product:
- 3. © 2019 Tasktop Oh My.
- 4. © 2019 Tasktop Does moving to Product Value Streams really involve all of that? Oh My.
- 5. © 2019 Tasktop DISCLAIMER Tasktop is not 30,000 people!
- 6. © 2019 Tasktop GARTNER CIO SURVEY 2019 55% of IT organizations are moving from project to product Source: CIO.com, Making the shift to product-based IT, January 2019
- 8. 8 October 2019© Tasktop Budgeting Timeframes Success Teams Prioritization Risk Visibility
- 9. © 2019 Tasktop SYMPTOMS Even with the best intentions … 01 Us vs Them 02 Problems have to go too high up to get resolved 03 Lack of knowledge about and empathy for our customers 04 Felt more inward focused than outward focused 05 Were we *really* product focused truly all the way through the entire organization? 06 Investment decisions are “twice baked”
- 10. 8 October 2019© Tasktop Budgeting Timeframes Success Teams Prioritization Risk Visibility
- 11. © 2019 Tasktop
- 12. 8 October 2019© Tasktop Customer First PRODUCT THINKING
- 13. © 2019 Tasktop Budgeting Timeframes Success Prioritization Risk VisibilityTeams
- 14. © 2019 Tasktop Budgeting Timeframes Success Prioritization Risk VisibilityTeams
- 15. © 2019 Tasktop CEO VP Product Hub Product Manager Hub Product Analyst Hub User Experience VP Engineering Hub Engineering Team 1 Hub Engineering Team 2
- 16. © 2019 Tasktop CEO VP Product Hub Product Manager Hub Product Analyst Hub User Experience VP Engineering Hub Engineering Team 1 Hub Engineering Team 2 View of Team View of Team
- 17. © 2019 Tasktop CEO VP Product Hub Product Manager Hub Product Analyst Hub User Experience VP Engineering Hub Engineering Team 1 Hub Engineering Team 2 View of Team View of Team Creates a Product vs. Engineering attitude All difficult decisions have to go all the way to the CEO *Internal* View of Team – not the customer view of team
- 18. © 2019 Tasktop CEO VP Product Hub Product Manager Hub Product Analyst Hub User Experience VP Engineering Hub Engineering Team 1 Hub Engineering Team 2 Customer View of Team
- 19. © 2019 Tasktop CEO VP Product Hub Product Manager Hub Product Analyst Hub User Experience VP Engineering Hub Engineering Team 1 Hub Engineering Team 2 Customer View of Team The values of ”product thinking” embodies: CUSTOMER FIRST
- 20. © 2019 Tasktop CEO VP Product Hub Product Manager Hub Product Analyst Hub User Experience VP Engineering Hub Engineering Team 1 Hub Engineering Team 2
- 21. © 2019 Tasktop CEO VP Product Dev PVS Lead Hub Product Manager Hub Product Analyst Hub User Experience Hub Engineering Team 1 Hub Engineering Team 2
- 22. © 2019 Tasktop CEO VP Product Dev PVS Lead Hub Product Manager Hub Product Analyst Hub User Experience Hub Engineering Team 1 Hub Engineering Team 2 It is “we” that matches how our customers see us Decisions are pushed down – almost all made directly within a PVS or between PVSs (Dependencies still matter)
- 23. © 2019 Tasktop What Happened
- 24. © 2019 Tasktop What Happened because of What Happened
- 25. © 2019 Tasktop New role: Product Value Stream Lead Moved from a Product Team and an Engineering Team to a single Product Development Team with 4 Product Value Streams 2 internal facing Product Value Streams 2 external facing Product Value Streams What Happened
- 26. © 2019 Tasktop Top Level Default Structure Product Value Stream Lead Engineering Manager Product Manager
- 27. 8 October 2019© Tasktop tProduct Value Stream Lead
- 28. 8 October 2019© Tasktop tProduct Value Stream Lead Sorry, no results found …
- 29. © 2019 Tasktop Product Value Stream Lead vs. Product Manager
- 30. © 2019 Tasktop You need BOTH NEITHER are Project Managers Product Value Stream Lead vs. Product Manager
- 31. © 2019 Tasktop
- 32. © 2019 Tasktop
- 33. © 2019 Tasktop
- 34. © 2019 Tasktop
- 35. © 2019 Tasktop PVS Lead Product Manager Whole picture: Business, Operational, Technical Significant people management duties Generally no feature design Primary Flow Metrics: Flow Distribution & Flow Efficiency Prioritization, prioritization, prioritization Generally no people management duties Feature Design Primary Flow Metrics: Flow Time, Flow Load & Flow Velocity
- 36. © 2019 Tasktop “The PVSL role creates team agency combining PM, design, and technical execution along with a whole business lens through all lifecycle phases. It has very little to do with being a PM. PM execution is a responsibility within this role.” “ First, it requires me to speak in terms of business results – almost exclusively about what we want to accomplish not how we want to accomplish it. As people in tech jobs go, I’m relatively un-enamored with technology so I don’t get wrapped up in technology for technology’s sake. Second, it forces me to delegate the role of technical lead to someone on the team. And this should serve to empower the team to do what they think is best.” PVS LEAD (Former Product Manager) PVS LEAD (Former Engineering Manager)
- 37. © 2019 Tasktop A GOOD PVS LEAD Business Minded “Multi-Lingual” People ManagerEmpathetic Vision Cares about how the sausage is made
- 38. © 2019 Tasktop Considerations Do you need other adjacent or cross cutting roles? Context & Background Matters Flexibility within PVSs Don’t be blind! Specific Individuals Matter
- 39. 8 October 2019© Tasktop Intentional vs. Perfect
- 40. 8 October 2019© Tasktop Simon says ….
- 41. 8 October 2019© Tasktop Simon says …. Carmen
- 42. 8 October 2019© Tasktop
- 43. © 2019 Tasktop Internal or Shared Services, Frameworks, Components
- 44. 8 October 2019© Tasktop Dependencies will exist. Relish them rather than shirk them.
- 45. 8 October 2019© Tasktop What Happened because of What Happened
- 46. © 2019 Tasktop “People don’t resist change, they resist loss”
- 47. © 2019 Tasktop Loss Map ? Being swallowed up – far more engineers Engineers Product ? All the sudden being responsible for technical details? ? Clarity (Perception) ?Concern of lost culture ? Being managed by non-engineers ? Would they no longer be insulated? ? Career path confusion? To be a PVS Lead?
- 48. © 2019 Tasktop Career Ladders
- 49. © 2019 Tasktop Product background or Engineering background? Resulting Optics & Tone Engineering Lead Product Lead Over compensate Ensure career tracks Communication with Executives Who Leads?
- 50. © 2019 Tasktop Does the story end here?
- 51. © 2019 Tasktop Oh My. Does the story end here?
- 52. © 2019 Tasktop “You want me to give you budget and revenue numbers based on what?” FINANCE SALES EXECS “Why are you talking to me about these ‘technical debt’ things?” “Am I going to get consistent reporting & visibility across all products?”
- 53. © 2019 Tasktop PVSs inherently unique Investors Product Value Streams Requires different reporting Flexibility: Customer & Internal Consistent Comparison Driven by traditional reporting and systems Laws The World of Finance Proxy Reporting x 2 Double Time & Work
- 54. © 2019 Tasktop Conversation Changers
- 55. © 2019 Tasktop
- 56. 8 October 2019© Tasktop Feature 1 Feature 2 -- Features -- Defects -- Risks -- Tech Debts April July October January Debt 1 Debt 2 FLOW DISTRIBUTION: Product X The ratio of the four Flow Items planned for the release
- 58. © 2019 Tasktop Pitfalls Change Management always the hardest part Tricky balance - “imposed upon” vs. “driven by” Recognize the entire organization won’t operate this way instantly PVSs is a terrible acronym © 2019 Tasktop Technologies Incorporated.
- 59. © 2019 Tasktop Victories Overall more of a customer focus Much less of an “us” vs. “them” – more of a “we are in this together” Investment decisions are easier to implement Consistency of Reporting
- 60. © 2019 Tasktop What’s next? Whole company – Common language Dependencies still viewed as “bad” Cross cutting roles Communication with Executives Can’t speed up time
- 61. © 2019 Tasktop Architect your end-to-end product value streams Learn how value is delivered across your organization Free one-hour consulting session will help you identify the product value streams within your organization today, visualize the flow of work, and help identify opportunities to make your value stream more tangible. www.tasktop.com/value-stream-architecture-consulting What’s next?
- 62. 8 October 2019© Tasktop Questions? @nicolebryan
Editor's Notes
- 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