More on this book
Kindle Notes & Highlights
by
Emrah Yayici
Read between
January 20 - January 22, 2022
1. Be Value Oriented - At each project, focus on generating outcomes (value) rather than outputs (deliverables).
focus on “must-have” rather than “nice-to-have" ones.
2. Be Customer Centered -Be like the sun but not the moon; illuminate yourself with the light of your own customers instead of your competitors.
Be customer centric rather than product centric. Consider products not as an objective but as a tool to meet your customers’ needs.
Always listen closely to the “voice of your customers”. Set up and maintain a continuous customer feedback loop.
“If I had asked people what they wanted, they would have said faster horses.”
3. Be Iterative -Think big, but start small. -Be patient; remember that Rome was not built in a day. -Move evolutionary rather than revolutionary.
4. Be Simplistic -Remember that less is much more. Do not complicate it. -Focus on “just enough” and what is really necessary to satisfy customer needs. -Appreciate downsizing the product by removing nonessential features, rather than upsizing it with bells and whistles.
5. Don’t Be Afraid of Early Failure -Remember the famous quotation from American scientist and author Dr. James Jay Horning: “Good judgment comes from experience. Experience comes from bad judgment.”
6. Optimize the Work Flow -Act “just in time”. Requirements analysis and design artifacts represent WIP (work in process) inventories in the development lifecycle. Create them at the right time and with sufficient detail to prevent WIP-level waste.
In other words, each project’s objectives (business requirements) should be aligned with corporate strategies.
In large-scale companies, this dedicated group may be a separate enterprise architecture team that works in coordination with company executives to understand business strategies, evaluate business unit requests against these strategies and steer technical teams in building products that meet today’s and tomorrow’s business and customer needs.
enterprise architects should guide technical teams in creating a flexible technical architecture that can serve both today’s and tomorrow’s new product development initiatives.
Thus in small- and midsized companies, project management offices (PMOs), product management teams, or a team of experienced business analysts should be responsible for evaluating and prioritizing product development/enhancement requests from all business units and ensuring the alignment of business and technical architectures.
Managing these requests is like managing the air traffic control tower at a very busy airport.
demand management pipeline creates a high technical debt.
Business units mostly criticize technical departments for not delivering new or enhanced products fast enough.
Similarly, project durations are relative for technical teams and business units of the same company. While six months will be considered a challenging time frame by most technical teams to develop a new product, it will be considered as a long duration by business units.
If you search for the root cause of technical teams’ latencies, you will see that they can only allocate limited time to the development of new products. They spend the majority of their time on an overwhelming number of enhancement/modification requests for existing products to "keep the lights on.”
“Keep the Lights On” Projects A high number of these enhancement / modification requests also demotivates business analysts, product managers, developers, and project managers because, instead of being involved in new and innovative projects, they have to spend their time firefighting existing products.
Usually this total amount outweighs the replacement of the existing product with a new one and creates product enhancement / modification-level waste.
Each product should have a separate maintenance and enhancement / modification track to identify the best time to totally replace it.
Company Overview The CEC sold TV sets, speakers, home cinema systems, and DVD players via independent dealer stores. These dealer stores were also responsible for product delivery and repair. The CEC worked with an outsourced call center company that was only responsible for customer service. It had no direct sales to customers. The CEC managed its procurement, inventory, accounting, and sales operations on an ERP system and marketing operations on a CRM system.
Business Need The CEC’s website was only being used to present product and campaign information. There were no sales on the web channel. At that time the CEC didn’t have a mobile application. For the last two years, discounted prices on e-commerce websites had been driving the CEC’s customers to the competition.
The company’s marketing business unit entered this request on the CEC’s demand management system as an urgent, high-priority demand. They noted that they wanted to release a mobile sales channel earlier than competitors, and thus the project had to be completed within two months at the latest.
The lean approach brings a purpose-led, value-oriented mindset that necessitates a shared vision among all project stakeholders.
Business analysts should start every project by defining the business requirements that explain the vision and value proposition of the product. Business requirements should clearly answer why customers need that specific product.
This mitigates the risk of scope creep due to potential change requests (CRs), which result in waste due to rework.
1. Business-Case Document In large-scale projects (usually called Type-A projects) that have enterprise-level impact, business requirements should be documented on a business-case document. The business-case document should include:
A clear explanation of the business need in a one-page SOW document is just enough to describe the scope of work.
Rippling Effect On any scope document, business requirements should be defined in specific, purpose-led, achievable, and crystal clear statements.
A clear definition of business requirements at the start of the project is very important, because at later stages of the project, the functional, nonfunctional, and technical requirements, and the business rules of the product should be defined consistent with the business requirements.
Paradox of Choice Having many features is not an indicator of elegance or quality in lean product development.
On the contrary, as psychologist Barry Schwartz describes it in his book Paradox of Choice: Why More Is Less, choice overload creates decision-making paralysis, anxiety, and stress rather than bringing more satisfaction to customers.
The items with high business value and low implementation difficulty should be rated as high priority, while the ones with low business value and high implementation difficulty should be rated as low priority.
Time to Market When time to market is critical for the product, the project should be classified as a “fast-track” one.
However, in our experience the majority of users only use a minority of the product features. This is big source of scope-level waste.
When business units insist on nice-to-have, low-priority features, business analysts and project managers should remind them of the famous phrase in Voltaire’s poem “La Begueule”: “perfect is the enemy of good.” The phrase suggests that insisting on perfection often results in no improvement at all.
Although benchmarking competitors’ products is a fast way of determining product features, it is not appreciated at every phase of lean product development.
“what problems of my target customers should my product solve” instead of “what my competitors are doing.”
After product features are defined, benchmarking can then be used to fasten later phases of product development by exploring how competitors implement similar features without reinventing the wheel.
In one of BA-Works projects, our team was responsible for benchmarking the customer interaction channels of a global hotel chain with its competitors.
majority of competitors had common right things and common wrong things on their customer-interaction channels (web, call center, mobile, and social media).
Although copying competitors is a fast way, companies should first focus on finding ways to differentiate themselves in prov...
This highlight has been truncated due to consecutive passage length restrictions.
Popular terms such as MVP (minimum viable product) and MMF (minimum marketable features) are used to define this core version of the product.
High-priority features on scope documents are the best candidates for the core version of the product. Medium- and low-priority features can be added to later releases according to customer feedback on the core version.
