If so, how would you actually go about doing it? Do you host workshops for developers and UX designers? How do you encourage them to come up with ideas?
Have you found that this approach adds value to both your team and the company?
Some developers don’t really engage in coming up with solutions to consumer concerns, while others are highly enthusiastic about it.
Your valuable inputs and insights would be highly appreciated.
Thanks in advance.
I’ve done this before in phases. The first usually involves the team’s development lead, and we basically discuss the issue and any potential answers. I wrote down any traps or holes that the developer mentioned throughout that talk. For instance, if there are tricky stored procedures they will need to work with or around, if a portion of the code is outdated and hasn’t been modified in X number of years, etc. Anything helps clarify the ask’s concept and give me a better idea of how I’ll cut the cards.
I’ll then hold a longer meeting with the UX, QA, and development teams to discuss the early pieces of the solution that we’ve already determined to be the quickest before handing the cards over to the team to refine. Next, we’ll discuss the strategy and note any new risks or worries. In general, once again, it’s a matter of problem-solving, and I place an emphasis on encouraging individuals to bring ideas rather than simply dismissing them. I then complete the cards, add any spikes or extra work we’ll want to include in the feature, and we’ll undertake a team-wide refinement.
It depends on various factors. In my experience, some developers are adept at handling uncertainty and are genuinely interested in understanding the “problem” we are attempting to solve. They are drawn to the idea of finding new products. Normally, I’d anticipate this from experienced developers. Therefore, it could be beneficial to incorporate one or two developers at an early stage. They can also provide context as needed and are much more sympathetic toward their clients or consumers because they participated in the discovery process.
I involve developers without a doubt. They can at the very least assist in directing our efforts. We don’t want to develop anything pricey only to spend the money when a few technical experts in the room will assist us cut down on wasteful expenses.
But I’ve discovered that enthusiastic engineers are more productive and offer brilliant ideas.
When we start discovery, I include the EM and bring in a dev as soon as I can. I also involve developers in prioritization to aid with providing approximate estimations and thoughts.
Each time I’ve delayed, we’ve usually had to add an extra cycle to redesign items to reduce costs, which also requires time to align people.
I think that in order to inspire individuals to come up with ideas, you need:
- Establish the goals. What issue are we attempting to solve and what solution are we seeking?
- Establish the parameters and context—why now? when will? at what price? What happens if we don’t, etc.?
- Establish measurable standards by which ideas will be assessed.
- Treat all ideas equally in the past.
- People are known to give even the most ridiculous proposals some thought.
- Evaluate the suggestion, but always thank and praise the individual who made it.
John Cleese gave an excellent speech about creation; I believe it can be found on YouTube. What I took from it, among other things, is the necessity of separating the stages of idea generation and idea evaluation.
In her idea of the Product Trio, Teresa Torres, in my opinion, provides a good model for incorporating engineering in ideation. She emphasizes the importance of involving engineers early in the ideation process to create feasible and viable solutions. By involving engineers early in the ideation process, it allows for a more holistic and efficient development of ideas. This ensures that technical constraints and considerations are addressed from the beginning, leading to more successful implementation of projects and higher chances of achieving desired outcomes. This approach also allows for better collaboration and integration of different perspectives, resulting in a more comprehensive and innovative solution.
Theoretically, they ought to be actively involved. Actually, it largely depends on the kinds of developers you have working for your organization. Some of the organizations where I’ve worked have largely only employed developers who weren’t interested in participating in research.
Other excellent places have specifically hired for this characteristic.
Most of them have a range. Find those who are interested in this and engage them. Don’t waste your time attempting to involve them if they don’t care. It is crucial to focus your efforts and resources on individuals who are genuinely interested in the research topic. This will increase the likelihood of success and meaningful contributions to the field of study. By engaging those who are truly invested, you can foster a sense of collaboration and enthusiasm that will drive progress and innovation.
Including developers in the initial stages of ideation can be highly beneficial for a project or company. Their technical expertise and understanding of the feasibility of ideas can help shape the ideation process in practical and innovative ways. Here’s how you can involve developers in the ideation process:
Cross-functional Workshops: Host cross-functional workshops that include developers, UX designers, product managers, and other relevant team members. These workshops can be focused on brainstorming, problem-solving, or envisioning future features. Ensure that developers feel their contributions are valued and essential to the ideation process.
Open Forums: Create an open forum or platform where team members can suggest ideas and discuss potential solutions. This can be an internal chat, project management tool, or dedicated ideation software. Encourage developers to participate and share their thoughts freely.
Hackathons or Innovation Days: Organize hackathons or innovation days where developers can work on creative projects or explore new ideas related to the company’s products or services. These events can foster a culture of innovation and allow developers to experiment with their ideas.
Cross-Training: Encourage cross-training sessions between developers and UX designers. This can help both sides better understand each other’s roles, constraints, and perspectives, fostering collaboration in the ideation process.
Idea Pitching: Allow developers to pitch their ideas directly to decision-makers or stakeholders. This can be done in a structured format, such as a pitch presentation or elevator pitch, to make it easier for developers to communicate their ideas effectively.
Recognition and Rewards: Recognize and reward developers for their contributions to the ideation process. This can include bonuses, promotions, or simply acknowledgment in team meetings. Positive reinforcement can motivate developers to actively engage in idea generation.
Feedback Mechanisms: Create feedback mechanisms that allow developers to provide input on the feasibility and technical challenges of proposed ideas. This ensures that ideas are not only creative but also executable within technical constraints.
Incorporating developers into the ideation process can add significant value to both the team and the company:
Technical Feasibility: Developers can identify potential technical challenges early on, helping the team avoid unrealistic or impractical ideas.
Innovation: Developers bring a unique perspective to ideation, which can lead to innovative solutions and features that may not have been considered otherwise.
Efficiency: Involving developers in the ideation process can streamline project development by aligning ideas with the team’s technical capabilities.
Engagement and Morale: When developers see that their ideas are valued and can contribute to the company’s success, it can boost their morale and engagement.
However, it’s essential to recognize that not all developers will have the same level of enthusiasm for ideation. Some may be more focused on the technical aspects of their work, while others may be eager to participate in brainstorming and problem-solving. It’s important to respect individual preferences while creating an inclusive ideation culture within the development team.
Unless the product is very technical (DBs, APIs, blockchain, etc.), I believe development time is too valuable to be wasted on pure ideation.
I visit the devs to have my ideas fact-checked. Can what I’m suggesting be put into action? When will it be finished? In the future, will assistance be simple? What dangers might there be? Will my ideas be implemented effectively?
Simply put, absolutely yes.
It sounds like the fact that PMs, developers, and UX are somewhat isolated is the greater issue you’re facing. They are cut off from the initial discovery, which distances them from the information and the clients. It’s not good.
Developers may thus turn into executioners as a result of this. They simply follow the instructions on the ticket or in the product specifications, which leads to numerous other issues.
A member of the product team must be a developer. They frequently have the highest level of intelligence in the room. In reality, I use the term “product development team” to describe it. You should think about reorganizing the team and modifying the culture.
By starting with this change, your team will be well on its way to developing more focus and agility. With practice, you’ll eventually deliver more quickly, pick up new skills more quickly, and provide your clients with real-world solutions.
In order to understand this cultural shift, Marty Cagan’s book Inspired is a great place to start.
I believe that introducing too many stakeholders leads to unnecessary noise. I have had a variety of experiences working with the tech community throughout the ideation stage because they are solution-focused individuals. If it is in the very early stages of brainstorming, I always include my UX man but not the IT guy. However, always keep them informed. In addition, I use Coda to document everything and share it with important engineering and design personnel, allowing them to self-serve and add comments as necessary.
Sincere reply: I would hold off on involving a developer unless it was absolutely necessary. The most valuable resource is development time. It should be used efficiently and only for essential tasks. It should not be wasted on non-essential tasks. It is important to prioritize and carefully consider which tasks require developer involvement. This will ensure that development time is optimized and focused on tasks that truly require it.
I explained the issue to the designers and engineers. Through their managers, I do it. They invite anyone they want at any time. We three work on setting priorities, so they are already aware. They already have ideas when it comes time to actually begin formulating a solution, which greatly speeds up the process. This greatly speeds up the process, allowing them to quickly start implementing a solution. This allows them to solve the problem more efficiently and effectively. This ultimately leads to a more successful outcome and saves valuable time and resources. By minimizing errors and streamlining processes, organizations can maximize productivity and achieve their goals more quickly.
In my opinion, it’s important to start with one or two weapons-grade developers, but for reasons that are probably different from yours: For example, it is very simple to save a lot of time and money by having a Dev remark, “Yeah; we can’t do that,” or “We can do that, but the juice isn’t worth the squeeze.” Secondarily, I see their own ideas as the cherry on top since it gives them a vision of how the building should look given the elements they are thinking of. In conclusion, involving the clients in the design process not only adds a personal touch to the project, but also ensures that their preferences are considered and incorporated into the final design.
Classic PM answer, but it depends:
If it’s something I foresee having major technical implications, limitations, or tradeoffs, I will. Especially if I have a good lead or engineering manager to bring in.
I don’t always, though. Often times, it’s a waste of their time.