PTSoftware teams innovate when they learn together with the client
Apps, platforms and subscription systems are digital services, and the people who invent and improve them are development teams. The thesis listened to 12 people from 9 software companies and built, from those conversations, a theory of how these teams learn, earn the client’s trust and create value with them. Explained in 12 screens.
The literature usually studies separately what teams live through together
Innovating in a digital service, learning as an organization and creating value with the client are three subjects with their own research. According to the thesis, field studies that bring all three together are rare, and that is what it set out to do. Tap each idea:
Sections 1, 1.3 and 2 of the thesis. The definitions are the ones the thesis adopts (Helkkula et al., 2018; Witell et al., 2016; Prahalad and Ramaswamy, 2004; Takahashi, 2015), summarized by us.
The research listened to 12 people from 9 software companies
Developers, architects, product managers and entrepreneurs described, in open conversations over Teams, how their team invents and improves services with clients. The interviews ran from November 2023 to September 2024. See the group by:
Sections 3.3 and 3.4, Tables 8 and 9 and Appendix D. Totals by breakdown and total conversation time are our counts. The cubes carry no code: we do not link anyone to a role, company or region. One company had 4 people interviewed, within the same team and neighbouring teams.
The theory was built step by step, upward from what people said
In grounded theory, the research does not start from hypotheses: it reads each statement line by line, names what is happening there (a code) and groups those names into ever broader ideas. Follow a real quote up the steps:
Sections 3.5 and 4.1 to 4.4, Tables 10 and 17 and Appendix E. The 708 excerpts are the sum of Table 10 (our count, 42 to 78 per person). Layer area is proportional to the count. Coding was done in Atlas.ti, by hand according to the thesis.
Understanding the client’s business and giving the team autonomy were the most tagged subjects
The number next to each code is how many times it was applied to an interview excerpt (the thesis calls it groundedness). Compare the two levels:
The thesis itself warns, following Charmaz, that this count does not measure importance: it shows part of the codes and points to where ideas cluster. The full list of 91 focused codes was not published (it is available on request); here are the most used.
Table 11 (initial codes used 10 times or more) and Table 12 (extract of focused codes, the top 12). Names shortened by us; the colour is our grouping.
Nine big ideas organize what the teams described
The 25 categories became 9 theoretical codes, the highest step before the theory. Each block’s height is the number of categories it groups. Tap a block:
Table 18 and Figures 4 to 13. The blocks add up to 27 entries, not 25: the thesis uses the numbers of two categories (CT.22 and CT.24) for different names in codes 4 and 6. We show each code with the names from its own section (dashed border).
The team learns from within and with the client, and slow feedback hurts both
The thesis found four sources of learning. Three sit inside the team; the fourth comes from outside. Choose:
How long does client feedback take to reach the people who did the work? Move the slider:
Sections 4.4.1 and 4.4.3. The slider is our illustration of one person’s account (P1): the thesis does not measure how long feedback takes or how many people have moved on.
Showing the client what is still imperfect can build trust
Before you look: the team takes an unfinished, "ugly" prototype to the client and admits what it does not know yet. What do you think happens to the relationship?
Abstract, sections 4.4.2, 5.1 and 5.2.1 (propositions 3 and 4), Appendix E. The literature the thesis draws on (Neghina, 2015) lists trust among the drivers of co-creation but does not say how to build it; vulnerability is the mechanism the thesis proposes. The thesis says "may": it is a proposition drawn from the interviews, not a measured effect.
Keeping what already exists eats into the time for inventing the new
Legacy systems, support tickets and documentation compete for the same hours as innovation. The thesis links this to a classic idea (March, 1991): exploring the new and exploiting what exists compete for the same resources. Each square is 1% of one interviewee’s time:
Sections 4.3, 4.4.6 and 4.4.7. The 30% and 70% are one person’s estimate (P3) of their own year; the thesis does not measure teams’ time. The slider is our illustration.
Before asking "can we build it?", the team asks whether it should
Teams innovate through three lenses: the technology, the client’s problem and the product. For the thesis, none is enough on its own, and the problem comes first. Choose a lens:
in a small company with a small team looking at eight different market pain points, we end up bringing several small things and falling into the analogy of the duck—it flies, swims, and walks, but doesn’t do any of them well.P7, on lack of focus (theoretical code 9)
Sections 4.4.8, 4.4.9 and 5.2.1 (proposition 10). The "Can I make it? Should I make it?" line is attributed to Charles Eames and quoted by the thesis. The taller problem block is our illustration of the priority the thesis gives it, not a count.
Everything converges on building digital service innovation
The theory’s core category is a process: building digital service innovation. Learning, trusting, co-creating and withstanding pressure feed that process, in a cycle that repeats. The thesis sums up the links in 10 propositions. Tap an arrow or a number:
Figure 14 redrawn and sections 5.2.1 and 5.2.2. The propositions come from the interviews and are left for future studies to test. Code 2 was split in two (relationships and trust). Proposition 9 is about the search for ideas and, in the figure, its arrow leaves from implementation; we draw the arrow as in the figure.
Innovating in digital services takes learning, trust and protected time
For the author, innovation does not come from technical skill alone: it is a human, repeated process in which the team learns, experiments and creates with the client.
For technology and product leaders
- Adopt design thinking: empathy, prototype, test and client feedback, in cycles.
- Set aside moments and rituals for new work; without them, "the routine consumes us".
- Tolerate honest mistakes and explain to the team why each delivery matters.
For development teams
- Show prototypes early, still imperfect, to speed up feedback.
- Validate hypotheses before building, and start from the problem, not the tool.
- Create channels so client feedback reaches the people who did the work quickly.
For those who buy software
- Taking part in defining what has value helps the solution fit daily work. (our reading)
- Sharing outcome figures with the supplier, which interviewees say is rare, gives the team the feedback it lacks.
What this research does not say
- A closed theory. Data collection stopped at 12 interviews for lack of time, before theoretical saturation: each conversation still brought new ideas. · according to the author
- Rules for any company. Startups, software houses and traditional companies innovate differently; each type is worth studying separately. · according to the author
- A bias-free reading. What people said reflects their own experience, and the interpretation is one researcher’s; more coders and other sources would help. · according to the author
- The client’s side. Only team members were interviewed, all men: trust and co-creation appear from the developers’ point of view. · our observation
- Measured effects. The 10 propositions were not tested; they say what may happen, not how much. · our observation
Credits
NONATO, José Antônio Afonso. Organizational learning and value co-creation in the context of digital service innovation: a study on software development teams. Doctoral thesis (Business Administration) · Mackenzie Presbyterian University, São Paulo, 2025. Advisor: Prof. Dr. Gilberto Perez. Co-advisor: Prof. Dr. Diógenes de Souza Bido.
Research supported by CAPES (Brazil’s federal agency for graduate education). Interviews were recorded with participants’ consent, and they could withdraw at any time. Initial coding was done by hand in Atlas.ti; ChatGPT was used as a "thinking partner" in other stages (summaries, literature search, naming categories, reviewing codes and the text), as the thesis describes in Appendix F. People appear only by the thesis’s codes (P1 to P12), with no role, company or region. This version simplifies the work for a general audience.