This page reflects my current perspectives on product development, informed by ongoing experience and learning. It will be periodically updated to incorporate new insights.
A shared YouTube queue for a party sounds like a native feature, but the available options did not fit how I wanted to use it. Native playlists can cache changes, and “Add to queue” assumes that people share a device or local network. I wanted guests to use their own phones without joining my home Wi-Fi, while keeping playback in the native YouTube app already signed in to a Premium account on Android TV.
The approach became practical when I found that the Android TV app can be controlled through Android Debug Bridge. I built Show Manager as a small web app on a VPS. It sends commands over SSH to a Raspberry Pi in my home network, which then controls the TV through ADB. Guests scan a QR code from a display connected to the Pi and receive a 24-hour session. The system is unusual, but each part has a narrow responsibility. This lets me reuse devices and accounts I already have.
Search proved more difficult than playback. Search results do not reliably say whether a video is a good music video or an audio track with a static image. Show Manager combines YouTube video results with YouTube Music song results. It also keeps a local collection of videos we have already screened and ranks matching items first. This does not try to infer quality from incomplete metadata. It uses previous choices as a practical feedback loop while still leaving wider search available.
The mobile interface now supports selecting several results, putting one item next, and controlling play, pause, and skip. Guest access is limited to search, playback, and the transient queue. The trusted view adds more disruptive controls, including clearing the queue and toggling TV power through the same ADB path, along with saved playlists and imports. Rather than add a separate admin account, the reverse proxy distinguishes public QR traffic from Tailnet traffic. That access model fits one household deployment, but I would choose differently for a service used by unrelated users.
After using the system, I added a cached fallback playlist called Pippalot. One action replaces the party queue with a shuffled set of known videos, so the music can continue without each person searching. Runtime playback never fetches the source playlist. Maintenance is deliberately manual and append-only: an importer adds missing source items, keeps existing and manually added videos, and creates a backup before writing. The trusted interface also accepts individual YouTube links. This keeps the party path reliable without adding background synchronization that I would need to monitor.
Show Manager still handles its original job: editing a loop of images and videos for the always-on Raspberry Pi display and deploying it over SSH to mpv. I built the first version over a few days with coding agents, then kept changing it as real use exposed specific friction. It remains tied to my setup rather than becoming a general platform, but the source code is available on GitHub as a starting point for similar systems.
I had already been experimenting with web interfaces for Pi when I read a post by DODOREACH. People had asked for the Pi interface from an earlier post. Rather than release the finished app, DODOREACH shared a one-shot prompt for building your own. It gave me a good starting point for a new setup, which I then shaped around the way I work.
Pi Web gives me an interface where I can choose a project, start or resume a session, watch messages and tool calls as they happen, and keep several chats running. It works on my desktop and phone through Tailscale. Pi still handles models, login, tools, settings, and session files. I did not want the web app to become a second version of Pi that would always be catching up.
From the initial implementation, I kept adjusting the interface to match my preferences. I can attach images and text files, see how much model context is left, and read Markdown files under docs and plans without leaving the chat. The project picker lets me move between workspaces. On my phone, project and worker lists move into drawers so the conversation still fits the screen.
The supervisor and subagents were part of the goal from the start. Their main benefit is context management. The supervisor keeps the main conversation focused on the overall task, while each subagent handles a bounded job in its own session. Each subagent returns a structured handoff instead of adding its full transcript to the supervisor's context. I can still inspect the transcript when I need it. Pi Web can also run up to three subagents, with only one editing at a time. Parallel work is useful, but it is secondary.
Next, I want to make Pi Web more specific to each project. Each project could define its own deploy button, worker setup, and predefined scripts. I also want a file browser for inspecting files directly. I do not want to rebuild a full development environment in the browser. I want each project's common actions next to its Pi sessions.
In product development, the key question is “What to build?” This involves understanding user needs beyond their explicit requests and having a strong vision. Visionary thinking is crucial, especially when building a new product. Product developers must listen to users, but need to consider the feedback against their broader vision. A fast feedback loop between the developers, domain experts, and users is essential. There are many product discovery methods and frameworks that can help you to find what to build. Essentially, those come down to talking to customers, good communication, and fast feedback loops with all stakeholders.
Once you have figured out how to determine what to build, you need people to build it. You should have an inspired and competent team that is cross-functional and communicates well. Usually, there are some business stakeholders, a product manager, a designer, and engineers. The team should be empowered to have autonomy and ownership of the product. That is motivating and leads to better outcomes. A good team can find processes that work well for them by themselves, but there are also some well-established best practices that you should study, because successful companies end up having very similar systems at the core.
As the company grows, the significance of its organizational structure and the management of information flow become increasingly important. For small organizations, a flat structure can work well, while it is easy to keep everyone aligned with the company’s goals. However, with expansion, involving everyone in every aspect becomes impractical. Therefore, establishing effective strategies for information distribution is crucial. This ensures the right team members are informed and involved in crucial decisions, allowing the business to adapt to its growing complexity and maintain organizational efficiency.
As your product progresses through different stages, the approach to its development needs to adapt. In the early stages, particularly before achieving product-market fit, the focus should be on rapid implementation. Embracing technical debt is acceptable during this phase, as speed is key. If it turns out that the solution being developed is not the right one, the technical debt is discarded along with the solution. However, once the product becomes more established, priorities shift towards maintainability, scalability, and various optimizations. At this stage, technical debt adds friction to progress and must be managed carefully.