Process
-
The Ability to Improve
(while this article contains many general ideas, it is written from the perspective of product development.) If you don’t continually improve, you soon lose the ability to do so … This thought came after an associate described a company tha…
-
🧪 Is 13 board revisions too many?
I was in a meeting recently with a potential customer, and they said they did not want to go through 50 prototypes to get a product out the door. 50 is a bit of an exaggeration, but I routinely see printed circuit boards (PCBs) at version 1…
-
🛤️ When building connected products, two things have to go right
The first is architecture, decided partly up front: network topology, the protocol between processors, how function is partitioned across boards, real-time constraints, the data model, how firmware gets updated in the field, and how operati…
-
🧱 Foundations
While we have many options in choosing technology, there are a few foundational things that are prudent to put in place early. Each costs little while the system is young and a great deal to retrofit once devices are in the field. They also…
-
🧱 The hardest things
The magic of product development appears to live in the complex things: the clever circuit design, the brilliant algorithm, the integration of many technologies. Observation suggests the opposite. Success is grounded in doing the simple thi…
-
🚣 Rowing the race you need at the end
Daniel James Brown’s The Boys in the Boat follows the University of Washington eight-oar crew that won gold in Berlin in 1936. The part that stays with me is how they rowed the middle of a race. Washington was a come-from-behind crew. Othe…
-
🚧 Gatekeepers are ineffective
In the context of complex systems, gatekeepers are ineffective. In product development, a gatekeeper is often a middle manager who relays information from one person to another. As an example, we have been struggling for the past year to ge…
-
📥 Email is not a workflow
A recent meeting surfaced a problem: BOM changes in the engineering systems were not reliably reaching the production systems. “I told ’em” is how we had been doing things. We told manufacturing about the changes and handed over links to th…
-
🛠️ Tools or Processes?
What matters more – having better tools or better processes? One tends to enable, the other to restrict. Companies often split into tool-builder cultures (optimized for enabling engineers and teams) and process cultures (optimized for contr…
-
🛩️ Why did the Wright Brothers succeed?
While Samuel Langley had $100,000 (equivalent to $3.5 million today) in funding, a team of engineers, and Washington connections, the Wrights were bicycle mechanics from Dayton, Ohio with a fraction of those resources. Langley’s approach wa…
-
👥 The release is a language everyone understands
A release is a good way for developers to communicate with everyone else: What got done What changed How to use or build the latest version Where to get support or provide feedback A regular cadence for communication A standard format ever…
-
⚡ The essence of shipping faster
In recent conversations about why development schedules slip and what to do about it, several themes continue to come up: Openness - This is key to surfacing issues early. Safety - People must feel safe being transparent and speaking up. C…
-
🔀 What is the difference between MVP and Release First?
MVP (Minimum Viable Product) is a concept from Eric Ries’ Lean Startup methodology. The idea is to build the smallest possible version of a product that lets you test a hypothesis with real users. Instead of spending months building a full-…
-
✅ Each release is 100% done
One common problem in product development is developers not finishing a feature or task. They get it to 70% done and rush off to the next thing. Bugs linger, edge cases go unhandled, testing falls short, and the release process remains inco…
-
📦 The bare minimum to call something a release
What is the bare minimum to call something a release? Consider the following: A version that increments with every release. A changelog that describes what has changed for every version and why it matters. A clear identification of any ass…
-
❓ Release Questions
Some questions to consider about a release: When is it created? Where is it stored? What does it contain? How is it created? Who uses it? Why is it used? The “Wh- questions” are a powerful technique for analyzing anything we do.
-
🎉 The BIG 1.0 Release
BIG releases are appealing — the magical moment when everything comes together. The months or years of hard work that finally come to fruition. The excitement and fanfare of the BIG announcement. The accolades and admiration of customers an…
-
❓ What is the difference between "releasing" and "shipping"?
Someone asked: “What is the difference between releasing and shipping?” Are they the same thing? In one sense they are. However, drawing a distinction here—though somewhat arbitrary—is helpful in this context. Release: Make something availa…
-
🚨 Problems with not Releasing First
What is the downside of not Releasing First? Integration problems Manufacturing issues Last minute bugs appearing Lack of product fit (does not solve customer’s problem) The common theme is unforeseen problems that typically surface late …
-
🧠 The Human Factors
Gerald M. Weinberg once said: No matter what the problem is, it’s always a people problem. — Gerald M. Weinberg At its heart, release-first addresses the human element: Our propensity to procrastinate in getting releases out. Our fear th…
-
☝️ What do we mean by "First"?
What do we mean by Release “First”? Several things: First in the timeline of development. First thing we focus on during implementation. First priority. Simply put, implement the Big Green Button before implementing the actual deliverable…
-
🟢 The Big Green Button
The word “release” can be a noun (what gets released) or a verb (the process of producing a release). “What” and “How”. Many teams produce complete high-quality releases that allow them to produce or deploy something at some point in time. …
-
🧩 Why things fall apart at the end
As discussed in the previous two posts, things often go haywire near the end of a project cycle, right before the BIG Release. Why is this? Things seem to go so well at the beginning of the project. While it is impossible to detail every re…
-
🪞 The illusion of project meta-data
Many tools exist for managing and tracking projects: Jira, Trello, GitHub projects/issues, Notion, Airtable, Asana, MS Project, etc. These all can be very useful. Why then does effective project tracking remain so elusive? As mentioned in t…
-
🚢 What is the #1 problem in product development?
I’ll go first … a very common challenge is shipping on time and the resulting uncertainty to the business. We often add a 2-3x factor on any estimates, but sometimes even that is not enough. Shipping (delivering value) is the bottom line — …
-
🔮 Can we predict product development schedules?
Estimating or predicting product development is difficult. Teams often end up adding a 2-3x padding to any estimate, because bitter experience has taught them not to depend on their own estimates. There will always be a high degree of varia…
-
📖 When should you write the user manual?
Most of the time, teams write the user manual at the end of a product development cycle right before the Big 1.0 Release. It is one of those things that is not much fun, and teams subconsciously put it off while fighting bigger fires. But w…
-
🎬 Is a Demo the same as a Release?
Some development teams have a weekly demo where they might show what they are working on to others in the company or the customer, which is a great idea as it encourages hitting milestones and early feedback. However, is the “demo” just ano…
-
🚀 Shipping faster - what are the stakes?
What do project delays cost? The obvious thing is the loss of revenue. Time is money. However, there are other less tangible consequences: Customers lose interest. Team loses motivation. Supporting organizations (vendors/communities) may n…
-
🔍 It is often more work to review something than to do it
As an experienced person, I am sometimes called on to review something. This can be a frustrating, seemingly hopeless task. With one developer, I commented that he could write code faster than I could review it. While there are some issues …
-
🚀 How far do you take releases?
Thus far, we have defined a release as something that is useful and high-quality. Typically, we think of a release as something formal - v1.3.8 that is packaged, built, and announced. But we can push this further. What about pull requests? …
-
🎯 Standards for internal vs external releases
It is natural to think of internal releases as “low stakes” - if it crashes and burns, no big deal. It’s just an experiment, right? Near production release, we’ll toss it over the wall to QA/Manufacturing and find all the issues. This is pa…
-
🚀 Shipping faster leads to predictability
Shipping faster does not only mean getting to v1.0 faster (or even on time), but also many internal releases at a good rate. This is the only way to bring predictability into the development process.
-
🔄 Platform Thinking is a habit
Platform Thinking in the context of product development has many parallels to effective habits in personal life. With personal exercise, healthy eating, getting enough sleep, and reading good books - these are difficult to start, but easy o…
-
🔄 Breaking the AI slop cycle
“AI Slop” is a common expression describing a familiar phenomenon. It refers to sloppy code (or other assets) generated by AI that mostly works, lacks proper review, and may be poorly architected or implemented. The primary characteristic o…
-
🤔 Why > How > What
Why? Is this the right thing to build? How? Can it be done efficiently, repeatedly? What? The deliverable. These are listed in order of importance, which also corresponds to the level of difficulty. The trouble with “How” and “Why” is thes…
-
🥉 Good, fast, cheap - choose three
A familiar phrase states: “Good, fast, cheap. Choose two.” This is similar to the development triangle. Which states that everything is a tradeoff. However, improving all three becomes possible when doing things differently. That is the …
-
📝 DDPD - 🧪 TDPD - 🚀 RDPD
We have been discussing document, test, and release-driven development (doing these things first before implementing features). This ensures the product: Meets the customer’s needs (DDPD). Is quality (TDPD). Can be modified any time and re…
-
📝 DDPD - Document Driven Product Development
Building on TDPD and RDPD, Document-driven product development (DDPD) offers another perspective. Ideas: Document the feature from the user’s perspective before implementing anything. Keep the documentation close to the code (same repo, et…
-
🚀 RDPD - Release Driven Product Development
Yesterday we talked about Test-Driven Product Development. Release-driven product development is another perspective. Build the release/deployment mechanism before implementing the design. Automate as much of the release as possible. This …
-
🧪 TDPD - Test Driven Product Development
We’re familiar with TDD (test-driven development) in the software world. Basically the idea is to create unit tests before implementing a feature. What if we extend this to systems, hardware, and even mechanical? Write end-to-end system te…
-
🚀 The BIG Release vs. 🌊 a Continuous flow of Value
How do we look at a product release? As a big one-time event, where we spend heroic efforts to pull it over the finish line? Or as a continuous flow of high-quality value into the product (even before the customer ever sees it) that is main…
-
🔄 Three levels of workflow
There are three levels of workflow: Personal (what you do to get things done) Department/Discipline (How multiple people who do the same thing get things done – Example: PCB design) Cross-functional (How people who do different jobs intera…
-
🏗️ The difference between Product and Platform
Product is what you build. Platform is how you build. Most people build the first and outsource the second. After all, the product has the IP—the secret sauce—the valuable part. However, we observe in successful companies a focus on their i…
-
😊 Other ways to align the happy path
Yesterday, we discussed aligning the happy path in code. Are there other ways to align the “happy path”? (The happy path is the desired path where things are functioning as expected.) Some thoughts: Focus on your productive people - as a ma…
-
🔓 You should not be needed
An effective process, team, or organization should be able to continue on if any individual steps away for a bit, or forever. But, most people are insecure and like to be needed, so subconsciously structure things to require them to be pres…
-
📚 Without docs
Design files (mechanical, electrical, or software) contain the technical details that allow us to manufacture something in the moment, but they often don’t contain the “why”. Why is this mechanical feature present? Why is this circuit nece…
-
🌀 Complex systems are hard to predict
My wife makes sourdough, which is a multi-day process and at times unpredictable. Recently, the current batch was a little sluggish and not expanding like it should, so she “fed” it and left it on the counter. It took off during the night a…
-
🔄 Look for closed loops
Closed loop systems are stable. Why? Because they learn and self-correct. In any system, process, person, or organization, look for closed loops. If something is not working, chances are there is an open loop.
-
🔄 Close the loop with AI
There is a fascinating statement in a recent MIT study that claims 95% of organizations are getting zero return from GenAI investments. The core barrier to scaling is not infrastructure, regulation, or talent. It is learning. Most GenAI sy…
-
🤖 AI is the new compiler
There are two ways to use AI: Start with a vague prompt and keep prompting until we get the result we want. Point the AI at documentation, and keep updating the documentation until it is clear enough that AI can do the right thing. Even t…
-
🎉 200 posts
This marks the 201st post I’ve sent – 2/3’s of the way through the 300 bad posts. How is it going? I still enjoy the process and the thinking it brings. However, it is getting a little bit more difficult recently to keep the discipline, esp…
-
🔗 Integration, not isolation (part 2)
We recently discussed integration, not isolation from a technical perspective. In an organizational context, we can have integrated cross-functional teams, or isolated silos. And the easiest way to avoid silos is transparency and common sys…
-
🔄 Open loops -> technical debt
If something is corrected, it needs to be fed back and incorporated, so you don’t keep redoing the same stuff over and over and eventually bury yourself in technical debt. Effective organizations close the loop.
-
📝 What is my process for capturing experience? (part 3)
Reflection is another important aspect of the experience capture process. Do we carefully evaluate and critically think about what happened? We don’t do this to blame ourselves or others, but rather to recognize areas where we might improve…
-
📝 What is my process for capturing experience? (part 2)
In part 1, we discussed the importance of getting information into permanent mediums. Below are a some that I use: Workflowy. This is my 2nd brain with 1000’s of notes, links, howtos, etc. It is easy to share Workflowy notes with others as…
-
📝 What is my process for capturing experience?
After yesterday’s post, I was asked: “What’s your process to capture experience?” The most important thing is to get information out of transient mediums into permanent mediums. What are the attributes of a permanent medium? Searchable Per…
-
🧠 How to leverage experience?
To leverage experience, we need to capture it. And to capture it, we need process. Without this, leveraging the experience of our best people is at best random. If we can capture experience, then we have it forever, even when our best peopl…
-
🚀 Git driven CD -- you know what got deployed
Git driven CD (Continuous Deployment) typically means whenever you merge to main , or tag a repo, something automatically gets deployed. It can be something as simple as a static website being updated. One of the biggest advantages to this …
-
🔄 The secret to process
Process/workflows/tools should be good enough that they help the people doing the work. They are not just an administrative tool. Some examples: Git helps me manage my own work, so I use it even on personal projects where collaboration is …
-
⚙️ Fix systems, not people
We can rarely “fix” other people. Short of a divine conversion experience or a life-changing event, people don’t fundamentally change, no matter how much we plead, beg, threaten, cajole, encourage, etc. Certainly, some are more gifted with …
-
🧩 The three legs of YOUR Platform
Automation – start with a checklist. Collaboration – #1 rule is don’t view email as a permanent place to store information. Process – the habits of your organization.
-
💭 Thinking, Designing, Developing, Engineering ...
If we are thinking without writing, are we really thinking? If we are designing without sketching/drawing, are we really designing? If we are developing software without iterations/testing, are we really developing? If we are engineering wi…
-
⚡ Are your processes proactive or reactive?
There are two ways to implement a process. The traditional way is as a check to make sure people did everything right. This could be required documentation that is written after a project is finished, a separate QA department that runs test…
-
⚠️ When things go wrong ...
What do we do? Do we focus on who/what to blame? Or do we figure out a path forward. How we are going to prevent this problem in the future? Not by shaming someone into paralysis, but by fixing the process. By improving YOUR Platform. The o…